 |
|
| If you can't view the Datasheet, Please click here to try to view without PDF Reader . |
|
|
|
| If you can't view the Datasheet, Please click here to try to view without PDF Reader . |
|
|
| Datasheet File OCR Text: |
| atmel atsha204 atmel cryptoauthentication datasheet features ? secure authentication and validation device ? integrated capability for both host and client operations ? superior sha - 256 hash algorithm, hmac option ? best - in - class, 256 - bit key length; storage fo r up to 16 keys ? guaranteed unique 72 - bit serial number ? internal, high - quality random n umber g enerator (rng) ? 4.5 - kbit eeprom for keys and data ? 512 otp ( one time programmable ) bits for fixed information ? multiple i/o options ? high - speed, single- wire interface ? 1mhz i 2 c interface ? 2.0v ? 5.5v supply voltage range ? 1.8v ? 5.5v communications ? <150na sleep current ? extended, multi - level hardware security ? 8 - lead soic, 8 - lead tssop, 3 - lead sot23, 8 - pad udfn , and 3 - lead c ontact packages applications ? anti - clone protection for accessories, daughter cards, and consumables ? secure boot validation, software anti - piracy ? network and computer access control ? key exchange for encrypted downloads ? authenticated/encrypted communications for control networks figure 1. pin configurations pin nam e function sda serial d ata scl serial c lock i nput gnd ground v cc power s upply 8740d ? crypto ? 3 /12 v cc nc scl sda nc nc nc gnd 4 3 2 1 5 6 7 8 8-lead udfn bottom view nc nc nc gnd 1 2 3 4 8 7 6 5 8-lead soic v cc nc scl sda 8-lead tssop 1 2 3 4 8 7 6 5 nc nc nc gnd v cc nc scl sda 3 2 1 gnd v cc sda 3-lead sot23 3-lead contact 1 2 3 sda gnd v cc
atmel atsha204 [ datasheet ] 2 8740d ? crypto ? 3 /12 1. introduction the following sections introduce the features and functions of the atmel ? atsha204 authentication device . 1.1 applications the atsha204 is a member of the atmel c ryptoauthentication? family of high - security hardware authentication devices. it has a flexible command set that allows use for many applications, including the following: ? anti - counterfeiting validate that a removable, replaceable, or consumable client is authentic. example clients could be printer ink tanks, electronic daughter cards, or other spare parts. it can also be used to validate a software/firmware module or memory storage element. ? protection for firmware or media validate code stored in flash me mory at boot to prevent unauthorized modifications (aka secure boot), encrypt downloaded media files, and uniquely encrypt code images to be usable on a single system only. ? session key exchange securely and easily exchange stream encryption keys for use b y an encryption/decryption engine in the system microprocessor to manage such things as a confidential communications channel or an encrypted download. ? secure data storage store secret keys for use by crypto accelerators in standard microprocessors . it c an also be used to store small quantities of data necessary for configuration, calibration, epurse value, consumption data, or other secrets. programmable protection up through encrypted/authenticated reads and writes. ? user password checking validate user e ntered passwords without letting the expected value become known, map simple passwords to complex ones, and securely exchange password values with remote system. 1.2 device features the atsha204 includes an e lectrically e rasable p rogrammable r ead - only m emory ( eeprom) array that can be used for storage of keys, miscellaneous read/write, read - only or secret data, consumption logging, and security configuration. access to the various sections of memory can be restricted in a variety of ways and the configuration t hen locked to prevent changes. see section 2.1 , ? eeprom organization ,? for more details on the eeprom organization. the atsha204 features a wide array of defensive mecha nisms specifically designed to prevent physical attacks on the device itself or logical attacks on the data transmitted between the device and the system ( see section 3.4, ? security features ,? for more details ). hardware restrictions on the ways in which keys are used or generated, described in section 3.3 , ? key values ,? provide further defense against certain styles of attack. access to the device is through a standard i 2 c interface at speeds up to 1m bit/sec (see section 6 for details on this interface). it is compatible with standard serial eeprom i 2 c interface specifications. the device also supports a single - wire inte rface that can reduce the number of gpios required on the system processor and/or reduce the number of pins on connectors. the single - wire interface is described in more detail in section 5 , ? single - wi re interface .? using either the i 2 c or single - wire interface, multiple atsha204 devices can share the same bus, which saves processor gpio usage in systems with multiple clients such as different color ink tanks or multiple spare parts. see section 4.2 , ? sharing the interface ,? and section 8.10 , ? pause command ,? for more details on the way in which this is implemented. each atsha204 ships with a gu aranteed unique 72 - bit serial number. using the cryptographic protocols supported by the device , a host system or remote server can prove that the serial number is both authentic and not a copy. serial numbers are often stored in a standard serial eeprom, but these can be easily copied, and there is no way for the host to know if the serial number is authentic or a clone. the atmel atsha204 can generate high - quality random numbers and employ them for any purpose, including as part of the crypto protocols of this device . because each 256 - bit random number is guaranteed to be unique from all numbers ever generated on this or any other device , their inclusion in the protocol calculation ensures that replay attacks (re - transmitting a atmel atsha204 [ datasheet ] 3 8740d ? crypto ? 3 /12 previously successful transa ction) always fail. further information is found in section 3.4.2 , ? random number generator ,? and section 8.11 , ? random command .? system integrati on is eased with a wide supply voltage range (2.0v through 5.5v) and an ultra - low sleep current of <100na. complete dc parameters are found in section 7 , which describes multiple package options, including a tiny sot23 package with a footprint of only 2.5mm x 3mm. see section 11 , ? package drawings ,? for more details and ordering codes. see section 9 , ? compatibility ,? fo r information regarding compatibility with the atmel at88sa102s and atmel at88sa10hs, previous members of the atmel cryptoauthentication family. 1.3 cryptographic operation the atsha204 supports a standard challenge - response protocol to simplify programming. a t its most basic, the host system sends a challenge to the device in the client, which combines that challenge with a secret key via the mac command from the system, described in section 8.8 , ? mac comma nd ,? and sends the response back to the system. the device uses a cryptographic hash algorithm for the combination, which prevents an observer on the bus from deriving the value of the secret key, but allows the recipient to verify that the response is co rrect by performing the same calculation (combining the challenge with the secret) with a stored copy of the secret. due to the flexible command set of the atsha204, however, this basic operation can be expanded in many ways. using the gendig command (sect ion 8.5 , ? gendig command ?) the values in other slots can be included in the response digest, which provides an effective way of proving that a data read really did come from the device , as opposed to b eing inserted by a man - in - the- middle attacker. this same command can be used to combine two keys with the challenge, which is useful when there are multiple layers of authentication to be performed. the derivekey command (section 8.3 , ? derivekey command ?) implements a key rolling scheme. depending on the command mode parameter, the resulting operation can be similar to that implemented in a remote - controlled garage door opener. each time the key is used , the current value of the key is cryptographically combined with a value specific to that system, and the result forms the key for the next cryptographic operation. even if an attacker gets the value of one key, that key will be go ne forever with the next use. derivekey can also be used to generate new random keys that might be valid only for a particular host id, for a particular ti me period, or for some other restricted environment. each generated key is different from any other key ever generated on any device . by ?activating? a host - client pair in the field in this manner, a clone of a single client would not work on any other host. in a host - client configuration where the host (for instance, a mobile phone) needs to verify a client (for instance, an oe m battery), there is a need to store the secret in the host in order to validate the response from the client. the checkmac command (section 8.2 , ? checkmac command ?) allows the host device to securely store the client secret and hide the correct response value from the pins, returning only a yes/no answer to the system. where a user - entered password is a requirement, the checkmac command also provides a way to both verify the password without exposing i t on the communications bus as well as map the password to a stored value that can have much higher entropy. see section 3.3.6 for more details. finally, the hash combination of a challenge and secret key can be kept on the dev ice and xored with the contents of a slot to implement an encrypted read (section 8.12 , ? read command ?) , or it can be xored with encrypted input data to implement an e ncrypted write (section 8.14, ? write command ?). each of these operations can be protected against replay attacks by including a random nonce (section 8.9 , ? nonce command ,?) in th e calculation. all security functions are implemented using the industry - standard sha - 256 secure hash algorithm, which is part of the latest set of high - security cryptographic algorithms recommended by various governments and cryptographic experts. section 3.1 , ? sha - 256 ,? includes a reference to the algorithm details. if desired, the sha - 256 algorithm can also be included in an hmac sequence (see section 3.2 , ? hmac/sha -256 ,? and section 8.6 , ? hmac command ?). the atsha204 employs full - sized, 256- bit secret keys to prevent any kind of exhaustive attack. atmel atsha204 [ datasheet ] 4 8740d ? crypto ? 3 /12 2. device organization the device contains the following memory blocks: ? eeprom ? sram 2.1 eeprom o rganization the eeprom contains a total of 5312 bits, and is divided into the following zones: ? data a 512 - byte (4 - k bit) zone split into 16 general - purpose, read - only, or read/write memory slots of 32 bytes (256 bits) each that can be used to store keys, calibration data, model number, or other information related to the item to which the atmel atsha204 device is attached. each slot may have different access restrictions based on the valu es stored in the configur ation zone. within this document the nomenclature slot[yy] indicates the 32 - byte value stored in slot yy of the data zone. ? configuration an 88 - byte (704 - bit) zone that contains serial number and other id information as well as access permission information for each slot of the data memory. within this document t he nomenclature sn[a:b] indicates a range of bytes within a field of the configuration section. the 88 bytes are accessible from within a three - block address space. ? otp (one time programmable) a 64 - b yte (512 - bit) zone which can be used to store read - only data . prior to locking the otp zone, the bits may be freely written using the standard write command. the otp zone is accessible from within a two - block address space. within this document the nomencl ature otp[bb] indicates a byte within the otp zone, while otp[aa:bb] indicates a range of bytes. within this document, the terms ?slot? and ?block? are used interchangeably to mean a single, 256 - bit (32- byte) area of a particular memory zone. t he industry sha - 256 documentation uses the term ?block? to indicate a 512- bit section of the message input. in addition, the i/o section of this document uses the term ?block? to indicate a variable - length aggregate element transferred between the system and the devic e . many sections of this document refer to a keyid, which is equivalent to the slot number for those slots designated to hold ke y values. key #1 (sometimes referred to as key[1]) is stored in slot[1], and so on. while all 16 slots can potentially hold key s, those slots for which clear reads are permitted would not normally be used as keys by the crypto commands. in this specification, the nomenclature mode:b indicates bit b of the parameter mode. on shipment from atmel, the eeprom contains factory test data that can be used for fixed - value board testing. this data must be overwritten with the desired contents prior to locking the configuration and/or data sections of the device . see the atmel website for the document co ntaining the specific shipment values. atmel atsha204 [ datasheet ] 5 8740d ? crypto ? 3 /12 2.1.1 configuration zone the 88 bytes in the configuration zone contain manufacturing identification data, general device and system configuration, and access restriction control values for the slots within the da ta zone. the values of these bytes can always be obtained using the read command. the bytes of this zone are arranged as shown in table 2 -1 . table 2 -1. configuration z one byte # name description write read 0 ? 3 sn[0:3] part of the seria l number value see the s ection 2.1.1.2, ? special memory values in the config zone (bytes 0 ? 12) ? never always 4 ? 7 revnum device revision number see the s ection 2.1.1.2, ? special memory values in the config zone (bytes 0 ? 12) ? never always 8 ? 12 sn[4:8] part of the serial number value see the s ection 2.1.1.2, ? special memory values in the config zone (bytes 0 ? 12) ? never always 13 reserved set by atmel never always 14 i2c_enable bit 0: 0 = the device operates in single- wire interface mode 1 = the device operates in i 2 c interface mode bits 1 - 7 are ignored: these bits are set at the atmel factory, depending on the part number, and cannot be changed . never always 15 reserved set by atmel never always 16 i2c_address bit 0: ignored bits 1 - 7: fo r i 2 c interface parts, the most- significant seven bits of this byte form the device address value to which this device will respond. bits 1, 2, and 4- 7 are ignored for single - wire interface parts. bit 3 (ttlenable): 1 = the input levels are v cc referenced 0 = the input levels use a fixed reference see section 7.4.1 for more information. for devices in which the i 2 c interface is enabled this byte has a default value of 0xc9 on shipment from atmel . if config unlo cked always 17 rfu reserved for futu re use, must be written to 0x00 . if config unlocked always 18 otpmode 0xaa (read - only mode) = writes to the otp zone are forbidden when the otp zone is locked. r eads of all words are permitted . 0x55 (consumption mode) = not supported at this time con tact atmel for more information. 0x00 (legacy mode) = when the otp zone is locked, writes to the otp zone, reads of words 0 and 1, and 32 - byte reads are all forbidden. see section 9 for more information on compatibility w ith the atmel at88sa102s device . all other values of otp mode are r eserved and should not be used . if config unlocked always 19 selectormode if 0, then selector can always be written with updateextra. if non- zero , selector can only be written if it currently has a value of zero. see section 8.13 for more details . if config unlocked always 20 ? 51 slotconfig two bytes of access and usage permissions and controls for eac h slot of the data zone. see the slotconfig (bytes 20 ? 51) section below for more details. if config unlocked always atmel atsha204 [ datasheet ] 6 8740d ? crypto ? 3 /12 byte # name description write read 52,54,56,58 60,62,64, 66 useflag for ?single use? keys (section 3.3 ), this byte indicates how many times a key may be used before such use is disabled. applies to keys #0 - 7 only (byte 52 corresponds to key0, 54 to key1, and so on). initialized to 0xff. see section 3.3. if config unlocked always 53,55,57,59 61,63,65,67 updatecount for keys that can be updated with derivekey, these bytes indicate how many times this operation has been performed. applies to keys #0 - 7 only, (byte 53 corresponds to key0, 55 to key1 , a nd so on) . initialized to 0x00 . see sections 3.3 and 8.2. if config unlocked always 68 ? 83 lastkeyuse 128 bits to co ntrol limited use for keyid 15 . initialized to 0xff . see section 3.3. if config unlocked always 84 userextra 1- byte value that can be modified via the updateextra command after the d ata zone has been locked. via update extra cmd only always 85 selector se lects which device will remain in active m ode after the execution of the p ause command. see sections 8.10 and 8.13 for more details . via update extra cmd only always 86 lockvalue controls the ability to write the otp and data zones . 0x55 = unlocked 0x00 = locked on shipment from atmel, this byte has a value of 0x55 corresponding to the ?unlocked? state. after the lock command has been run, this byte will have a value of 0x00, corresponding to ?locked .? see sections 2.1.2 and 8.7 for more details . when locked, the otp zone can be modified only with the write command, and slots in t he data zone can be modified only if the corresponding writeconfig field so indicates. when unlocked, the read command is pr ohibited within these two zones . via lock command only always 87 lockconfig controls the ability t o modify the configuration zone . 0x55 = unlocked 0x00 = locked on shipment from atmel this byte has a value of 0x55 corresponding to the ?unlocked? state. after the lock command has been run, this byte will have a value of 0x00, corresponding to?locked .? see sections 2.1.2 and 8.7 for more details . via lock command only always atmel atsha204 [ datasheet ] 7 8740d ? crypto ? 3 /12 2.1.1.1 slotconfig ( b ytes 20 ? 51) the 16 slotconfig elements are used to configure the access protections for each of the 16 slots withi n the atsha204. each configuration element consists of 16 bits, which control the usage and access for that particular slot/key. the slotconfig fi eld is interpreted according to the following table when the data zone is locked. when the data zone is unlock ed, these restrictions do not apply ? all slots may be freely written and none may be read. table 2 -2. slotconfig bits (per slot) bit # name description 0 ? 3 readkey use this keyid to encrypt data being read from this s lot using the r ead command. if zero , then this slot can be the source for the checkmac copy operation (see section 3.3.6 ). see the description for bit 6 in this table, the read command description in section 8.12 , and table 2 -3 for more details. note: do not use zero as a default. do not set this field t o zero unless the checkmac copy operation is explicitly desired, regardless of any other read/write restrictions . 4 checkonly 1 = the key stored in the slot can be used only for checkmac command. it can also be used for gendig if the subsequent use of tempkey is checkmac. the key cannot be used by any other command, either directly as keyid in the input parameter list or via tempkey. 0 = the key stored in the slot can be used by all crypto commands . 5 singleuse 1 = the key stored in the slot is ?single use.? see section 3.3 for more details . ignored for keys in slots 8 -14. 0 = t here are no usage limitations . 6 encryptread 1 = reads from this slot will be encrypted using the procedure specified in the r ead command description (section 8.12 ) using readkey (bits 0 ? 3 in this table) to generate the encryption key. no input mac is required. if this bit is set , then issecret must also be set (see also table 2 - 3 ). 0 = cl ear text reads may be permitted. 7 issecret 1 = the contents of this slot are secret: clear text reads are prohibited, and both 4 - byte reads and writes are prohibit ed. this bit must be set if encryptread is one or if writeconfig has any value other than atmel atsha204 [ datasheet ] 8 8740d ? crypto ? 3 /12 read operations depend on the state of issecret and encryptread according to the following table: table 2 -3. read operation permissio n issecret encryptread description 0 0 clear text reads are always permitted from this slot . slots set to this state shoul d never be used as key storage . either 4 or 32 bytes may be read at a time . 0 1 prohibited. no security is guara nteed for slots usi ng this code . 1 0 reads are never permitted from this slot . slots set to this state ca n still be used for key storage . 1 1 reads from this slot are encrypted using the encryption algorithm documented in the read command description (s ee s ection 8.12 ). the encryption key is in the slot specified by readkey. 4 - byte reads and writes are prohibited . the 4 - bit writeconfig field is interpreted by the write and derivekey commands as shown in table 2- 4 a nd table 2 - 5 , where x means ?don?t care.? note: the tables overlap. for example, a code of 0110 indicates a slot that can be written in encrypted form using the w rite command and also can be the target of an unaut horized derivekey comman d with the target as the source . table 2 -4. write configuration bits ? write command bit 15 bit 14 bit 13 bit 12 mode name description 0 0 0 x always clear text writes are always permitted on this slot. slots set to ?a lways? should never be u sed as key storage. either 4 or 32 by tes may be written to this slot . 0 0 1 x never writes are never permitted on this slot using th e write command slots set to ?n ever? c an still be used as key storage . 1 0 x x never writes are never permitted on thi s sl ot using the write command slots set to ?n ever? c an still be used as key storage . x 1 x x encrypt writes to this slot require a properly computed mac, and the input data must be encrypted by the system with writekey using the encryption algorithm document ed in the write command description (section 8.13 ). 4 - byte writes to this slot are prohibited. table 2 -5. write configuration bits ? derivekey command bit 15 bit 14 bit 13 bit 12 source key (1) description 0 x 1 0 target derivekey comm and can be run without authorizing mac (roll) . 1 x 1 0 target authorizing mac required for derivekey command (roll) . 0 x 1 1 parent derivekey command can be run without authorizing mac (create) . 1 x 1 1 parent authorizing mac required for derivekey comm and (create) . x x 0 x ? slots with this value in the writeconfig field may not be used as the target of the derivekey command . note: 1. the source key for the computation performed by the derivekey command can either be the key directly specified in param2 (th e ?target?) or the key at slotconfig[p aram2].writekey (the ?parent?) see section 3.3 for more details . atmel atsha204 [ datasheet ] 9 8740d ? crypto ? 3 /12 the issecret bit controls internal circuitry necessary for prop er security for slots in which r eads and/or w rites must be en crypted or are prohibited altogether. it must also be set for all slots that are to be used as keys, including those created or modified with derivekey. specifically, to enable proper device operation, this bit must be set unless writeconfig is ?a lways.? 4 - byte accesses are prohibited to/from slots in which this bit is set. slots used to store key values should always have issecret set to one and encryptread set to zero (reads prohibited) for maximum security. for fixed key values, writeconfig should be se t to ?n ever.? when configured in this way, there is no way to read or write the key after the data zone is locked ? it may only be used for crypto operations. some security policies require that secrets be updated from time to time. the atsha204 supports t his capability in the following way: writeconfig for the particular slot should be set to ?encrypt? and slotconfig.writekey should point back to th e same slot by setting writekey to the slot id. a standard write command can be then used to write a new valu e to this slot provided that the authentication mac is computed using the old (current) key value. 2.1.1.2 special mem ory values in the config zone (b ytes 0 ? 12) various fixed information is included in the atsha204 that can never be written under any circumstanc es and can always be read, regardless of the state of the lock bits. ? serialnum nine bytes (sn[0:8]) which together form a unique value that is never repeated for any device in the cryptoauthentication family. the serial number is divided into two groups: 1. sn[0:1] and sn[8] the values of these bits are fixed at manufacturing time in most versions of the atmel atsha204. their default value is 0x01 23 ee. these 24 bits are always included in the sha - 256 computations made by the atmel atsha20 4 . 2. sn[2:3] and sn[ 4:7] the values of these bits are programmed by atmel during the manufacturing process and are different for every die. these 48 bits are optionally included in some sha - 256 computat ions made by the atmel atsha204 . ? revnum four bytes of information that a re used by atmel to provide manufacturing revision information. these bytes can be freely read as revnum[0:3], but should never be used by system software, as they may vary from time to time. 2.1.2 device locking there are two separate lock states for the device : 1. o ne to lock the configuration zone (controlled by lockconfig, byte 87) 2. s econd to lock both the otp and data zones (con trolled by lockvalue, byte 86) these lock bits are stored within separate bytes in the configuration zone, and can be modified only thr ough the lock command. after a memory zone is locked, there is no way to unlock it. the device should be personalized at the system manufacturer with the desired configuration information, after which the configuration zone should be locked. when this lock is complete, all necessary writes of public and secret information into the eeprom slots should be performed, using encrypted writes if appropriate. upon completion of any writes, the data and otp sections should be locked. contact atmel for optional secu re personalization services. it is vital that the data and otp sections be locked prior to release of the system containing the device into the field. failure to lock these zones may permit modification of any secret keys and may lead to other security pro blems. any attempt to read or write the data or otp sections prior to locking the configuration section causes the device to return an error. atmel atsha204 [ datasheet ] 10 8740d ? crypto ? 3 /12 2.1.2.1 configuration zone locking certain bytes within the configuration zone cannot be modified, regardless of the s tate of lockconfig. access to the remainder of the bytes within the zone is controlled using the lockvalue byte in the configuration zone, as shown in the following tabl e. throughout this document, if lockconfig is 0x55, the configuration zone is said to b e unlocked; otherwise it is locked. table 2 -6. configuration zone locking read access write access lockvalue == 0x55 (unlocked) read write lockvalue != 0x55 (locked) read atmel atsha204 [ datasheet ] 11 8740d ? crypto ? 3 /12 2.2 static ram (sram) the device includes an sram array that is used to store the input command or output result, intermediate computation values, and/or an ephemeral key. the entire contents of this memory are always invalidated whenever the device goes into sleep mode or the power is removed. the ephemeral key is named tempkey, and c an be used as an input to the mac, hmac, checkmac, gendig, and derivekey commands. it is also used as the data protection (encryption or decryption) key by the read and write commands. see below for more details on tempkey. 2.2.1 tempkey tempkey is a storage reg ister in the sram array that can be used to store an ephemeral result value from the nonce or gendig commands. the contents of this register can never be read from the device (although the device itself can read and use the contents internally). this regis ter contains the elements shown in table 2 -8 . table 2 -8. tempkey storage register name length description tempkey 256 bit s (32 byte s) nonce (from n once command) or digest (from gendig command) keyid 4 bits if tempkey was generated by g endig (see the gendata and checkflag bits), these bits indicate which key was used in its computation. the four bits represent one of the slots of the data zone . sourceflag 1 bit the source of the randomness in tempkey: 0 = internally generated random nu mber ( rand ). 1 = input seed only, no internal random generation ( input ). gendata 1 bit 0 = tempkey.keyid is not meaningful , and is ignored . 1 = the contents of tempkey were generated by gendig using one of the slots in the data zone (and tempkey.keyid will be meaningful) . checkflag 1 bit if 1, the contents of tempkey were generated by the gendig command and at least one of the keys used in that generation is restricted to the checkmac command (s lotconfig.checkonly is 1). otherwise, this bit will be 0. valid 1 bit 0 = the information in tempkey is invalid . 1 = the information in tempkey is valid . in this specification, the name ?tempkey? refers to the contents of the 256 - bit data register. the remaining bit fields are referred to as tempkey.sourcef lag, tempkey.gendata, and so on. the tempkey.valid bit is cleared to zero under any of the following circumstances: ? power up, sleep, brown out, watchdog expiration, or tamper detection. the contents of tempkey, however, are retained when the device enters idle mode . ? after the execution of any command other than nonce or gendig, regardless of whether or not the command execution succeeds. it may be cleared by the checkmac command unless a successful copy takes place. it is not cleared if there is a communica tions problem, as evidenced by a cyclic redundancy check (crc) error . ? an error during the parsing or execution of gendig and/or nonce . ? execution of gendig replaces any previous output of the nonce command with the output of the gendig command. execution of the nonce command likewise replaces any previous output of the gendig command . atmel atsha204 [ datasheet ] 12 8740d ? crypto ? 3 /12 3. cryptographic information the atsha204 implements a challenge - response protocol using either sha - 256 or hmac/sha - 256, details are below. the response is always a 256 - bit diges t. the nonce command (see section 8.9 ) accepts an input challenge from the system and optionally combines it with an internally generated random number to generate a nonce (number used once) for the calculation. this seed is th en combined with a secret key as part of the authentication calculation for any of the crypto commands (mac, hmac, read, write, or gendig). for compatibility reasons, the input challenge may be passed directly to the mac command; however, this operation is deprecated. the device can guarantee the uniqueness of the nonce only if the device has included the output of its random number generator in the calculation, because the system input may or may not be unique. every random nonce is guaranteed to be unique when compared to all previous nonces, ensuring that each transaction is unique over all time. 3.1 sha -256 the atsha204 mac command calculates the digest of a secret key concatenated with the challenge or nonce. it optionally includes various other pieces of i nformation stored on the device within the digested message. the atsha204 computes the sha - 256 digest based on the algorithm documented here: http://csrc.nist.gov/publications/fi ps/fips180 - 2/fips180 - 2.pdf the complete sha - 256 message processed by the atsha204 is listed in sections 8.5 and 8.9 for each of the particular commands (gendig and nonce) that use the algorithm. most standard software implementations of the algorithm automatically add the appropriate number of pad and length bits to this message to match the operation the device performs internally. the sha - 256 algorithm is also used for encryption by taking the output digest of the hash algorithm and xoring it with the plain text data to produce the ciphertext. decryption is the reverse ? the ciphertext is xored with the digest, and the result is the plain text. 3.2 hmac/sha -256 the resp onse to the challenge can also be computed using the hmac algorithm based on sha - 256 documented here: http://csrc.nist.gov/publications/fips/fips198/fips - 198a.pdf because of the increased computation complexity, the hmac command is not as flexible as the mac command and the computation time for hmac is extended. while the hmac sequence is not necessary to ensure the security of the digest, it is included for compatibility with var ious software packages. 3.3 key values all keys within the cryptoauthentication family are 256 bits long. the atsha204 uses these keys as part of the messages hashed with the mac, checkmac, hmac, and gendig commands. any slot in the data zone of the eeprom can be used to store a key, though the value will be secret only if the read and write permissions are properly set within slotconfig (inclu ding the issecret bit). except for the gendig command, all but the least - significant four bits of the keyid parameter a re ignored in determining the source of key data. only the least - significant four bits are used to select one of the slots of the data zone. see section 3.3.7, below, for information on how gendig uses other keyid values. in al l cases for which a sha - 256 calculation is performed using param2, the entire 16- bit keyid as input is included in the message. atmel atsha204 [ datasheet ] 13 8740d ? crypto ? 3 /12 3.3.1 diversified keys if the host or validating entity has a place to securely store secrets, the key values stored in the eeprom slo t(s) can be diversified with the serial number embedded in the device (sn[0:8]). in this manner, every client device can have a unique key, which can provide extra protection against known plaintext attacks and permit compromised serial numbers to be ident ified and blacklisted. to implement this, a root secret is externally combined with the device serial number during personalization using some cryptographic algorithm and the result written to the atsha204 key slot. the atsha204 checkmac command provides a mechanism of securely generating and comparing diversified keys, eliminating this requirement from the host system. consult the following application note for more details: ht tp://www.atmel.com/dyn/resources/prod_documents/doc8666.pdf 3.3.2 rolled keys in order to prevent repeated use of the same key value, the atsha204 supports key rolling. normally, after a certain number of uses (perhaps as few as one), the current key value is replaced with the sha - 256 digest of its current value combined with some offset, which may either be a constant, something related to the current system (for example, a serial number or model number), or a random number. this capability is implemented usin g the derivekey command. prior to execution of the derivekey command, the nonce command must be run to load the offset into tempkey. each time the roll operation is performed on slots 0 - 7, the updatecount field for that slot is incremented. one use for thi s capability is to permanently remove the original key from the device, replacing it with a key that is only useful in a particular environment. after the key is rolled, there is no possible way to retrieve the old value, which improves the security of the system. note: any power interruption during the execution of the derivekey command in roll mode may cause either the key or the updatecount to have an unknown value. if writing to a slot is enabled using bit number 14 of slotconfig, such keys can be written in encrypted and authenticated form using the write command. alternatively, multiple copies of the key can be stored in multiple slots so that failure of a single slot does not incapacitate the system. 3.3.3 created keys in order to support unique ephemeral keys f or every client, the atsha204 also supports key creation. in this mechanism, a ?parent? key (specified by slotconfig.writekey) is combined with a fixed or random nonce to create a unique key, which is the n used for any cryptographic purpose. the ability t o create unique keys is especially useful if the parent key has usage restrictions (see ? single - use keys ? and ? limited- use key ? in the following sections). in this mode, the limited use parent key can be employed to create an unlimited use child key. because the child key is useful only for this particular host - client pair, attacks on its value are less valuable. this capability is also implemented using the derivekey command. prior to execution of the der ivekey command, the nonce command must be run to load the nonce value into tempkey. each time the create operation is performed on slots 0 - 7; the updatecount field for that slot is incremented. 3.3.4 single - use keys for the keyid values corresponding to slots 0 - 7 in the data section of the eeprom, repeated usage of the key stored in the slot can be strictly limited. this feature is enabled if the singleuse bit is set in the slotconfig field. the singleuse bit is ignored for slots 8 - 14. the number of remaining use s is stored as a bit map in the useflag byte corresponding to the slot in question. prior to execution of any cryptographic command that uses this slot as a key, the following takes place: ? if slotconfig[keyid].singleuse is set and useflag[keyid] is 0x00, t he device returns an error . ? starting at bit seven of useflag[keyid], clear to zero the first bit that is currently a one . atmel atsha204 [ datasheet ] 14 8740d ? crypto ? 3 /12 in practice, this procedure permits singleuse keys to be used eight times between ?refreshes? using the derivekey command. if power is lost during the execution of any command referencing a key that has this feature enabled, one of the use bits in useflag may still be cleared even though the command did not complete. for this reason, atmel recommends that the key be used a single time on ly, with the other bits providing a safety margin for errors. under normal circumstances, all eight useflag bytes should be initialized to 0xff. if it is the intention to permit fewer tha n eight uses of a particular key, these bytes should be initialized t o 0x7f (seven uses), 0x3f (six uses), 0x1f (five uses), 0x0f (four uses), 0x07 (three uses), 0x03 (two uses), or 0x01 (one use). initialization to any other value besides these values or 0xff is prohibited. the read, write, and derivekey commands operate s lightly differently: ? read and write these commands ignore the state of the singleuse bit and the useflag byte does not change as a result of their execution. singleuse slots in which the useflag is exhausted (value of 0x00) can still be read or written (su bject to the appropriate slotconfig limitations) although the value in the slot cannot ever be used as a key for cryptographic commands. if slotconfig.writekey for slot x points back to x, but useflag[x] is exhausted, encrypted writes to the slot will ne ver succeed because the prior gendig command will have returned an error due to the usage limitation. a similar situation occurs with reads and readkey. slots used as keys should never have issecret set to zero or writeconfig set to always. ? derivekey if th e parent key is used for either authentication or as the source, then if singleuse (for the parent) is set and useflag (also for the parent) is 0x00, the derivekey command returns an error. the singleuse and useflag bits are ignored for the target key. whe n successfully executed, derivekey always resets the useflag to 0xff for the target key ? this is the only mechanism to reset the useflag bits. use of the derivekey command is optional ? it is legal to be run only if writeconfig: 13 is set for this slot. i n some situations, it may be advantageous to simply have a key that can be used eight times, in which case the other crypto commands will clear the bits in useflag one at a time until all are cleared, and at which time the key is disabled. 3.3.5 limited - use key if slot[15].singleuse is set, usage of key number 15 is limited through a different mechanism than the single - use limitation described above, which applies only to slots 0 -7. prior to any use of key 15 by a cryptographic command, the following takes place: ? if all bytes in lastkeyuse are 0x00, return error . ? starting at bit seven of the first byte of lastkeyuse (byte 68 in config zone), clear to zero the first bit that is currently a zero. if byte 68 is 0x00, check bit seven of byte 69, and so on up through b yte 83. only a single bit is cleared each time prior to using key 15 . there is no reset mechanism for this limitation ? after 128 uses (or the number of one bits set in lastkeyuse on personalization), key 15 is permanently disabled. this capability is not susceptible to power interruptions ? even if the power is interrupted during execution of the command, only a single bit in lastkeyuse will be unknown; all other bits in lastkeyuse wi ll be unchanged and the key will remain unchanged. if fewer than 128 uses are desired for key 15, then some of the bytes within this array should not be initialized to 0xff. as with useflag, the only legal values for bytes within this field (besides 0xff) are 0x7f, 0x3f, 0x1f, 0x0f, 0x07, 0x03, 0x01, or 0x00. the total number o f bits set to one indicates the number of uses. one example of how to set 16 uses is as follows: 0xff, 0xff, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00. the singleuse bit is ignored by the read and write commands, an d lastkeyuse does not change as a result of their execution. the singleuse bit is ignored by the copy function of the checkmac command. the singleuse bit is honored for the parent key in the derivekey command, but is ignored for the target key. atmel atsha204 [ datasheet ] 15 8740d ? crypto ? 3 /12 3.3.6 password ch ecking many applications require a user to enter a password to enable features, decrypt stored data, or some other purpose. typically, the expected password has to be stored somewhere in memory and is, therefore, subject to discovery. the atsha204 can sec urely store the expected password and perform a number of useful operations on it. the password is never passed in the clear to the device , nor can it be read from the device . it is hashed with a random number in the system software before being passed to the device . the copy capability of the checkmac command enables the following types of password checking options: 1. checkmac does an internal comparison with the expected password and returns a boolean to the system to indicate whether the passwo rd was corre ctly entered or not . 2. if the device determines that the correct password has been entered, then the value of the password can optionally be combined with a stored or ephemeral value to create a key that can be used by the syst em for data protection purposes . 3. if the device determines that the correct password has been entered, the device can use this fact to optionally release a secondary, high entropy secret, which can be used for data protection without risk of a ny exhaustive dictionary attack . 4. if the passw ord has been lost, an entity with knowledge of a parent key value can optionally write a new password into the slot. also optionally, the current value can be encrypted with a parent key and read fro m the device . passwords should be stored in even - numbered slots. if the password is to be mapped to a secondary value (use # 3 above), then the target slot containing this value is located in the next higher slot number (the password slot number plus one). otherwise, the target slot i s the same as the password slot. readkey for the target slot must be set to zero to enable this capability. in order to prevent fraudulent or unintended usage of this capability, do not set readkey for any slot to zero unless this checkmac/copy capability is specifically required. in particular, do not assume that other bits in the configuration word for a particular slot override the enablement of this cap ability specified by readkey = 0. this capability is enabled only if the mode parameter to checkmac h as a value of 0x01, indicating : a. the first 32 bytes of the sha - 256 message are stored in a data slot in the eeprom (the password) . b. the second 32 bytes of the sha - 256 message must be a randomly generated nonce in the tempkey register . if the above conditions are met and the input response matches the internally generated digest, then the contents of the target key are copied to tempkey. the other tempkey register bits are set as follows: ? sourceflag is set to one (not random) ? gendata is set to zero (not gener ate by the gendata command) ? checkflag is set to zero (tempkey is not restricted to the checkmac command) ? valid is set to one 3.3.7 transport keys the atsha204 device includes an internal hardware array of keys (transport keys) that are intended for secure person alization prior to locking of the data section. the values of the hardware keys are kept secret, and are made available to qualified customers upon request to atmel. these keys can be used with the gendig command only, and are indicated by a keyid value 0x8000. this is the intended personalization command flow: 1. write intended values to the configuration zone, and then lock the configuration zone. 2. write non - secret slots and otp zone, data should be passed to the device in the clear. 3. generate a random perso nalization key in any one of the secret slots with the following sequence: a. nonce command to generate a random nonce in tempkey b. gendig specifying a transport key 0x8000 c. gendig using the compliance (default) value stored in the slot to be used for perso nalization d. encrypted w rite to that same slot (overwrites the compliance value) atmel atsha204 [ datasheet ] 16 8740d ? crypto ? 3 /12 4. u se that personalization key to write all the secret slots, ending with the final value of the personalization key slot itself, using the following sequence repeated as necessa ry: a. nonce command to generate a random nonce in tempkey b. gendig specifying the personalization key c. encrypted write to the target slot 5. lock the data zone for gendig and all other commands, keyid values less than 0x8000 always reference keys that are store d in the data zone of the eeprom. in these cases, only the four least - significant bits of keyid are used to determine the slot number, while the entire 16 - bit keyid as input is used in any sha - 256 message calculation. 3.4 security features 3.4.1 physical security th e atsha204 incorporates a number of physical security features designed to protect the eeprom contents from unauthorized exposure. the security measures include: ? an a ctive s hield o ver the p art ? internal m emory e ncryption ? secure t est m odes ? glitch p rotection ? voltage t amper d etection pre - programmed transport keys stored on the atsha204 are encrypted in such a way as to make retrieval of their values using outside analysis very difficult. both the logic clock and logic supply voltage are internally generated, p reventing any direct attack on these two signals using the pins of the device . 3.4.2 random number generator (rng) the atsha204 includes a high - quality random number generator that returns 32 random bytes to the system. the device combines this generated number with a separate input number to form a nonce that is stored within the device in tempkey and may be used by subsequent commands. the system may use this random number generator for any purpose. one common purpose would be as the input challenge to the mac command on a separate cryptoauthentication device . the device provides a special random command for such purposes, which does do not affect the internally stored nonce. to simplify system testing, prior to config locking the random number generator always returns the following value: ff ff 00 00 ff ff 00 00 ? where ff is the first byte read from the device and the first byte into the sha message. to prevent replay attacks on encrypted data that is passed to or from the atsha204, the device requires that a new, internally generated nonce be included as part of the encryption sequence used to protect the data being written or read. to implement this requirement, the data protection key generated by gendig and used by the read or write command must use the in ternal random number generator during the creation of the nonce . random numbers are generated from a combination of the output of a hardware random number generator and an internal seed value, which is not externally accessible. the internal seed is stored in the eeprom, and is normally updated once after every power - up or sleep/wake cycle. after the update, this seed value is retained in registers within the device that are invalidated if the device z enters sleep mode or the power is removed. because there is an eeprom endurance specification that limits the number of times the eeprom seed can be updated, the host system should manage power cycles to minimize the number of required updates. in certain circumstances, the system may choose to suppress the eep rom seed update using the mode parameter to the nonce and random commands. atmel atsha204 [ datasheet ] 17 8740d ? crypto ? 3 /12 because this may affect the security of the system, it should be used with caution. see section 8.9 and section 8.11 for mo re information about how the eeprom seed update is controlled. 4. general i/o information communications with the atsha204 are achieved through one of two different protocols, and selected using the part number that is ordered: ? single - wire interface this mod e u ses a single gpio connection on the system microprocessor connected to sda on the device . it permits the fewest number of connector pins to any removable/replaceable e ntity. the bit rate is up to 26 - kbits/sec . ? i 2 c interface this mode is compatible with the atmel at24c16b s erial eeprom interface. two pins, s erial d ata (sda) and s erial c lock (scl) are required. the i 2 c interface supports a bit rate of up to 1m bit/sec. the lowest levels of the i/o protocols are described below in sections 5 and 6 . above the i/o protocol level, however, exactly the same bytes are transferred to and from the device to implement the cryptographic commands and error codes documented in section 8 . note: the device implements a failsafe internal watchdog timer that forces it into a very low power mode after a certain time interval, regardless of any current activity. system programming must take this into consideration. see section 8.1.6 for more details. 4.1 byte and bit ordering cryptoauthentication uses a common ordering scheme for bytes and also for the way in which numbers and arrays are represented in this datasheet: ? all multi - byte aggregate elements are treated as array s of bytes and are processed in the order received or transmitted with index #0 first . ? 16- bit (2 - byte) integers, typically param2 appear on the bus least - significant byte first . in this document, the most - significant bit or nibble of a byte or 16- bit word appears towards the left hand side of the page. the bit order is different depending on the i/o channel used: ? on the one - wire interface, data is transferred to/from the atmel atsha204 least - significant bit first on the bus . ? on the i 2 c interface, data is tr ansferred to/from the atmel atsha204 most - significant bit first on the bus . 4.1.1 output example the following bytes will be returned in this order on the bus by a 32 - byte read of the configuration section with an input address of 0x0000: sn[0], sn[1], sn[2], sn [3], revnum[0], revnum[1], revnum[2], revnum[3], sn[4], sn[5], sn[6], sn[7], sn[8], reserved, i2c enable, reserved, i2c_address, tempoffset, otpmode, selectormode, slotconfig[0].read, slotconfig[0].write, slotconfig[1].read, slotconfig[1].write, slotconfig [2].read, slotconfig[2].write, slotconfig[3].read, slotconfig[3].write, slotconfig[4].read, slotconfig[4].write, slotconfig[5].read, slotconfig[5].write 4.1.2 mac message example the following bytes will be passed to the sha engine for a mac command using a mode value of 0x71 and a keyid of slot x. in the example below, k[x] indicates the keyid of slot x in the data zone, with k[0] being the first byte on the bus for a re ad from or write to that slot. otp[0] indicates the first byte on the bus for a read of the o tp zone at address zero, and so on. k[0], k[1], k[2], k[3] ? k[31], tempkey[0], tempkey[1], tempkey[2], tempkey[3] ? tempkey[31], opcode (=0x08), mode (=0x71), param2(lsb = x), param2(msb = 0), otp[0], otp[1], otp[2], otp[3], otp[4], otp[5], otp[6], otp[7 ], otp[8], otp[9], otp[10], sn[8], sn[4], sn[5], sn[6], sn[7], sn[0], sn[1], sn[2], sn[3]. for more details regarding mac messages, see section 8.8 , ? mac command .? atmel atsha204 [ datasheet ] 18 8740d ? crypto ? 3 /12 4.2 sharing the interface multiple crypto authentication devices may share the same interface, as follows: a. system issues a wake token (see section 5.1 ) to wake up all devices . b. the system issues the pause command to put all but one of the devices into idle mode. only th e remaining device then sees any commands the system sends. when the system has completed talking to the one active device, it sends an idle flag, which the idle devices ignore but which puts the single remaining active device into the idle mode. see secti on 8.10 , ? pause command ,? for more details. steps a and b are repeated for each device on the wire. if the system has completed communications with the final device , it should wake all the device s up a nd then put all the device s to sleep to reduce total power consumption. the device uses the selector byte within the configuration zone to determine which device stays awake ? only that device with a selector value that matches the input parameter of the p ause command stays awake. in order to facilitate late configuration of systems that use the multi - device sharing mode, the following three update capabilities for the selector byte are supported: 1. unlimited updates at any time, the updateextra command can b e executed to write the value in the selector field of the configuration zone. to enable this mode, set the selectormode byte in the configuration zone to zero. 2. one - time field update if the selectormode byte is set to a non - zero value and the selector byte is set to a zero value prior to locking the configuration zone, then at any time after the configuration zone is locked the updateextra command can be used one time to set selector to a non - zero value. the updateextra command is not affected by the lockva lue byte. 3. fixed selector value the selector byte can never be modified after the configuration zone is locked if both selectormode and selector are set to non - zero values. the updateextra command will always return an error code. 5. single - wire interface in t his mode, communications to and from the atsha204 take place over sda, a single, asynchronously timed wire, and the scl pin is ignored. note: the sleep current specification values are guaranteed only if the scl pin is held low or left unconnected. the overall communications structure is a hierarchy: tokens i/o tokens implement a single data bit transmitted on the bus, or the wake - up event. flags flags consist of eight tokens (bits) that convey the direction and meaning of the next group of bits (if any) that may be transmitted. blocks blocks of data follow the command and transmit flags. they incorporate both a byte count and a checksum to ensure proper data transmission. packets packets of bytes form the core of the block (minus the byte count and c rc). they are either the input or output parameters of a cryptoauthentication command or status information from the atmel atsha204. see the atmel website for the appropriate application notes for more details on how to use any microprocessor to easily gen erate the signaling necessary to send these elements to the device , including c source code libraries. also, see section 10.2 , ? wiring configuration for single - wire interface ,? for more information abo ut how to connect the device in the single - wire interface mode. atmel atsha204 [ datasheet ] 19 8740d ? crypto ? 3 /12 5.1 i/o tokens there are a number of i/o tokens that may be transmitted over the single - wire interface: input : (to the atmel atsha204) wake wake the device up from either sleep or idle states . zero send a single bit from the system to the device with a value of zero . one send a single bit from the system to the device with a value of one . output : (from the atmel atsha204) zeroout send a single bit from the device to the sy stem with a value of zero . one out send a single bit from the device to the system with a value of one . the waveforms are the same in either direction. there are some differences in timing, however, based on the expectation that the host has a very accu rate and consistent clock, while the atsha204 has significant part -to - part variability in its internal clock generator, due to normal manufacturing and environmental fluctuations. the bit timings are designed to permit a standard uart running at 230.4k bau d to transmit and receive the tokens efficiently. each byte transmitted or received by the uart corresponds to a single bit received or transmitted by the device . the wake token is special in that it requires an extra long low pulse on the sda pin, which cannot be confused with the shorter low pulses that occur during a data token (zero, one, zeroout, oneout). device s that are in either the idle or sleep state ignore all data tokens until they receive a legal wake token. do not send a wake token to device s that are awake, as they will lose synchronization because the waveform can be resolved to nei ther a legal one nor zero. see s ection 5.3.2 for the procedure to regain synchronization. 5.2 i/o flags the system is always the bus mas ter, so before any i/o transaction, the system must send an 8 - bit flag to the device to indicate the i/o operation to be subsequently performed, as shown in table 5 -1 . table 5 -1. i/o flags value name meaning 0x77 command after this flag, the system starts sendi ng a command block to the device . the first bit of the block can follow immediately after the last bit of the flag . 0x88 transmit this command tells the device to wait for a bus turnaround time and then start transmitting its respo nse to the previ ously transmitted command block . 0xbb idle upon receipt of an idle flag, the device goes into the idle mode and remains there until the next wake token is received . 0xcc sleep upon receipt of a sleep flag, the device enters the low - power sleep mode until the next w ake token is received . all other values are reserved and should not be used 5.2.1.1 transmit flag the transmit flag is used to turn the bus around so that the atsha204 can send data back to the system. the bytes that the device return s to the system depend on the current state of the device , and may include either status, error code, or command results. when the device is busy executing a command, it ignores the sda pin and any flags sent by the system. see table 8 -4 for execution delays in the device for each command type. the system must observe these delays after sending a command to the device . atmel atsha204 [ datasheet ] 20 8740d ? crypto ? 3 /12 5.2.1.2 idle flag the idle flag is used to transition the atsha204 to the idle state, which causes the input/output buf fer to be flushed. it does not invalidate the contents of the tempkey and rng seed registers. this flag can be sent to the device at any time when it will accept a flag. when the device is in the idle state, the watchdog timer is disabled. 5.2.1.3 sleep flag the sleep flag transitions the atsha204 to the low - power sleep state, which causes a complete reset of the device , including invalidation of the contents of the sram and all volatile registers. this flag can be sent to the device at any time when it will accep t a flag. 5.3 synchronization because the communications protocol is half - duplex, there is the possibility that the system and the atsha204 will fall out of synchronization with each other. in order to speed recovery, the device implements a timeout that force s it to sleep under certain circumstances. 5.3.1 i/o timeout after a leading transition for any data token has been received, the atsha204 will expect the remaining bits of the token to be properly received by the device within the t timeout interval. failure to send enough bits or the transmission of an illegal token (a low pulse exceeding t zlo ) will cause the device to enter the sleep state after the t timeout interval. the same timeout applies during the transmission of the command block. after the transmission of a legal command flag, the i/o timeout circuitry is enabled until the last expected data bit is received. note: the timeout counter is reset after every legal token, and so the total time to transmit the command may exceed the t timeout interval whil e the ti me between bits may not . the i/o timeout circuitry is disabled when the device is busy executing a command. 5.3.2 synchronization procedures if the device is not busy when the system sends a transmit flag, the device should respond within t turnaround . if t exec time has not already passed, the device may be busy, and the system should poll or wait until the maximum t exec time has elapsed. if the device still does not respond to a second transmit flag within t turnaround , it may be out of synchronization. at this point, the system may take the following steps to reestablish communication: 1. wait t timeout . 2. send the transmit flag . 3. if the device responds within t turnaround , then the system may proceed with more commands . 4. send a wake token . 5. wait t whi . 6. send the transmit flag . 7. the device should respond with a 0x11 status within t turnaround , at which time system may proceed with commands . any command results in the i/o buffer may be lost when the system and device lose synchronization. atmel atsha204 [ datasheet ] 21 8740d ? crypto ? 3 /12 6. i 2 c interface the i 2 c interface uses the sda and scl pins to indicate various i/o states to the atsha204. this interface is designed to be compatible at the protocol level with the at24c16b s erial eeprom operating at 1mhz. the sda pin is normally pulled high with an external pull - up res istor, as the atsha204 includes only an open - drain driver on its output pin. the bus master may be either open ? drain or totem pole, and if the latter, then it should be tri - stated when the atsha204 is driving results on the bus. the scl pin is an input, an d must be driven both high and low at all times by an external device 6.1 i/o conditions the device responds to the following i/o conditions: 6.1.1 device is asleep when the device is asleep, it ignores all but the wake condition wake : if sda is held low for a per iod greater than t wlo , the device exits low - power mode and, after a delay of t whi , is ready to receive i 2 c commands. the device ignores any levels or transitions on the scl pin when the device is idle or asleep and during t wlo . at some point during t whi , t he scl pin is enable d and the conditions listed in s ection 6.1.2 , ? device is awake ,? are honored. the wake condition requires either that the system processor manually drive the sda pin low for t wlo , o r that a data byte of 0x00 is transmitted at a clock rate sufficiently slow that sda is low for a minimum period of t wlo . when the device is awake, the normal processor i 2 c hardware and/or software can be used for device communications up to and including the i/o sequence required toput the device back into low power (sleep) mode. when there are multiple atsha204 device s on the bus and the i 2 c interface is run at 133khz or slower, the transmission of certain data patterns (such as 0x00) will cause all the a tsha204 device s on the bus to wake up. because subsequent device addresses transmitted along the bus will only match the desired device s, the unused devices will remain idle and not cause any bus conflicts. in i 2 c mode, the device will ignore a wake sequen ce sent when the device is already awake. 6.1.2 device is awake when the device is awake, it honors the conditions listed below. data zero: if sda is low and stable while scl goes from low to high to low, then a zero bit is being transferred on the bus. sda can change while scl is low. data one: if sda is high and stable while scl goes from low to high to low, then a one bit is being transferred on the bus. sda can change while scl is low. figure 6 -1. data bit transfer on i 2 c interface sda scl data line stable; data valid change of data allowed atmel atsha204 [ datasheet ] 22 8740d ? crypto ? 3 /12 start : a high -to - low transition of sda with scl high is a start condition, which must precede all commands. stop : a low -to - high transition of sda with scl high is a stop condition. after this condition is received by the device , the current i/o transaction ends. on input, if the device ha s sufficient bytes to execute a command, the device transitions to the busy state and begins execution. the stop condition should always be sent after any packet sent to the device . figure 6 -2. start and stop conditions on i 2 c interface sda scl s t a r t condition stop condition s p acknowledge (ack): on the n inth clock cycle after every address or data byte is transferred, the receiver will pull the sda pin low to acknowledge proper reception of the byte. not acknowledge (nack): alternatively, on the ninth clock cycle after every address or data byte is trans ferred, the receiver can leave the sda pin high to indicate that there was a problem with the reception of the byte or that this byte completes the block transfer. figure 6 -3. nack and ack conditions on i 2 c interface data output by transmitter data output by receiver c lo ck pu ls e f o r a ck no wl edge m en t s t a r t condition s scl from master n o t ack no wl edg e ack no wl edg e 1 2 8 9 multiple atsha204 device s can easily share the sa me i 2 c interface if the i2c_device address byte is programmed differently for each device on the bus. because six of the bits of the device address are programmable, the atsha204 can also share the i 2 c interface with any standard i 2 c device , including any serial eeprom. bit 3 (also known as ttl enable) must be programmed according the input thresholds desired, and is fixed in a particular application. atmel atsha204 [ datasheet ] 23 8740d ? crypto ? 3 /12 6.2 i 2 c transmission to the atmel atsha204 device the transmission of data from the system to the at88sa102s i s summarized in figure 6 - 4 . the order of transmission is: ? start c ondition ? device a ddress b yte ? word a ddress b yte ? optional d ata b ytes (1 through n) ? stop c ondition figure 6 -4. normal i 2 c transmission to an atmel atsha204 sda scl 1 - 7 8 9 1 - 7 8 9 1 - 7 8 9 1 - 7 8 9 1 - 7 8 9 s p start condition device address w ord address data 2 ack 1 ack 1 ack 1 ack 1 ack 1 stop condition data n data 1 r/w note: sda is driven low by the atmel atsha204 during the ack periods the tables below label the bytes of the i/o transaction. the i 2 c n ame column provides the names of the bytes as described in the at24c16b datasheet. table 6 -1. i 2 c transmission to atmel atsha204 atmel atsha204 i 2 c name description device a ddress device a ddress this byte selects a particular device on the i 2 c interface. the atmel atsha204 is selected if bits 1 - 7 of this byte match bits 1- 7 of the i2c_address byte in the configuration zone. bit 0 of this byte is the stand ard i 2 c r/w bit, and should be zero to indicate a w rite operation (the bytes following the device address travel from the master to the slave). word a ddress word a ddress this byte should have a value of 0x03 for normal operation . see s ections 6.2.2 and 6.6 , below , for more information . command data1 - n the command block, consisting of the count, command packet, and the two - byte crc. the crc is calculated over the size and packet bytes. see s ection 8.1 . because the device treats the command input buffer as a fifo, the input block can be sent to the device in one or many i 2 c command blocks. the first byte sent to the device is the count, and so after the device receives t hat number of bytes, it will ignore any subsequently received bytes until execution is finished. the system must send a stop condition after the last command byte to ensure that the atsha204 will start the computation of the command. failure to send a stop condition may eventually result in a loss of synchroni zation (s ee section 6.7 for recovery procedures). atmel atsha204 [ datasheet ] 24 8740d ? crypto ? 3 /12 6.2.1 word address values during an i 2 c write packet, the atsha204 interprets the second byte sent as the word address, which indicates the packet function, as described in the following table. table 6 -2. word address values name value description reset 0x00 reset the address counter. the next r ead or w rite transaction will start with the beginning of the i / o buffer . sleep (low power) 0x 01 the atmel atsha204 goes into the low - power sleep mode and ignores all subsequent i / o transitions until the next w ake flag. the entire volatile state of the device is reset. idle 0x02 the atmel atsha204 goes into the idle state and ignores all subsequen t i/ o transitions until the next w ake flag. the contents of tempkey and rng s eed registe rs are retained . command 0x03 write subsequent bytes to sequential addresses in the input command buffer that follow previous write s. this is the normal operation . re served 0x04 ? 0xff these addresses should not be sent to the device . 6.2.2 command completion polling after a complete command has been sent to the atsha204, the device will be busy until the command computation completes. the system has two options for this d elay: ? polling the system should wait t exec (typical) and then send a read sequence (s ee section 6.5 ). if the device nacks the device address, then it is still busy. the system may delay for some time or immediately send another read sequence, again looping on nack. after a total delay of t exec (max), the device will have completed the computation and return the results. ? s ingle delay the system should wait t exec (max), after which the device will have completed execution and the result can be read from the device using a normal read sequence. 6.3 sleep sequence upon completion of system use of the atsha204, the system should issue a sleep sequence to put the device into low - power mode. this sequence consists of the proper device addre ss followed by the value of 0x01 as the word address followed by a stop condition. this transition to the low - power state causes a complete reset of the device internal command engine and input/output buffer. it can be sent to the device at any time when i t is awake and not busy. 6.4 idle sequence if the total sequence of required commands exceeds t watchdog , then the device will automatically go to sleep and lose any information stored in the volatile registers. this action can be prevented by putting the devic e into the idle state prior to completion of the watchdog interv al. when the device receives the w ake token, it will then restart the watchdog timer, and execution can be continued. the idle sequence consists of the proper device address followed by the va lue of 0x02 as the word address followed by a stop condition. it can be sent to the device at any time when it is awake and not busy. if tempkey was created as a result of the copy mode of the checkmac command, it will not be retained when the part goes in to an idle state. atmel atsha204 [ datasheet ] 25 8740d ? crypto ? 3 /12 6.5 i 2 c transmission from the atmel atsha204 device when the atsha204 is awake and not busy, the bus master can retrieve the current buffer contents from the device using an i 2 c read. if valid command results are available, the size of the bl ock returned is determined by the particu lar command that has been run (s ee section 8 . ? commands ?), otherwise the size of the block (and the first byte returned) will al ways be four: count, status/error, and 2 - byte crc. the bus timing is shown in figure 7- 3 in section 7.3.2 . table 6 -3. i 2 c transmission from atmel atsha204 atmel atsha204 i 2 c na me direction description device a ddress device a ddress to slave this byte selects a particular device on the i 2 c interface , and the atmel atsha204 will be selected if bits 1 - 7 of this byte match bits 1- 7 of the i2c_address byte in the configuration zone. bit 0 of this byte is the standard i 2 c r/w pin, and should be one to indicate that the bytes following the device address travel from the slave to the master (read) . data data 1,n to master the output block, consisting of the count and status/error byte or the output packet followed by the two - byte crc per s ection 8.1 . the status, error, or command outputs can be read repeate dly by the master. each time a r ead command is sent to the atsha204 along the i 2 c interface, the device transmits the next sequential byte in the output buffer. see the following section for details on how the device handles the address counter. if the atsha204 is busy, idle, or asleep, it will nack the device address on a read sequence. if a partial comman d has been sent to the device , then it will nack the device address, but float the bus during the data intervals. 6.6 address counter writes to and/or reads from the atsha204 i/o buffer over the i 2 c interface are treated as if the device were a fifo. either th e i 2 c byte or block write/read protocols can be used. the number of bytes transferred with each block sequence does not affect the operation of the device . the first byte transmitted to the device is treated as the size byte. any attempt to send more than this number of bytes or any attempts to write beyond the end of the i/o buffer (84 bytes) will cause the atsha204 to nack those bytes. after the host writes a single command byte to the input buffer, reads from the host are prohibited until after the devi ce completes command execution. attempts to read from the device prior to the last command byte being sent will result in an ack of the device address but all ones (0xff) on the bus. if the master attempts to send a read byte to the device during command e xecution, the device will nack the device address. data may be read from the device under the following three conditions: ? on power up, the single byte, 0x11 ( s ee section 8.1.3 ), can be read inside a four byte block . ? if a comple te block has been received by the device , but there are any errors in parsing or executing the command, a single byte of error code is available, also inside a four byte block . ? upon completion of command execution, from 1 - 32 bytes of command result are ava ilable to be read inside a block of 4 - 35 bytes . any attempt to read beyond the end of the valid output buffer returns 0xff to the system ? the address counter does not wrap around to the beginning of the buffer. there may be situations where the system ma y wish to re - read the output buffer; for example, when the crc check reveals an error. in this case, the master should send a two - byte sequence to the atsha204 consisting of the correct device address and a word address of 0x00 (reset, per table 6 -2 ), followed by a stop condition. this causes the address counter to be reset to zero, and permits the data to be re - written (re - read) to (from) the device . this address reset sequence does not prohibit subsequent read operations if da ta was available for reading in the i/o buffer prior to the sequence execution. after one or more read operations to retrieve the results of a command execution, the first write operation resets the addres s counter to the beginning of the i/o buffer. atmel atsha204 [ datasheet ] 26 8740d ? crypto ? 3 /12 6.7 i 2 c s ynchronization it is possible for the system to lose synchronization with the i/o port on the atsha204, perhaps due a system reset, i/o nois e, or other condition. under this circumstance, the atsha204 may not respond as expected, may be asleep, or may be t ransmitting data during an interval when the system is expecting to send data. any command results in the i/o buffer may be lost when the system and device lose synchronization. to re - synchronize, the following procedure should be followed: 1. to ensure an i/ o channel reset, the system should send the standard i 2 c software reset sequence, as follows: ? a start condition ? nine cycles of scl with sda held high ? another start condition ? a stop condition it should then be possible to send a read sequence, and, if synch ronization has completed properly, the atsha204 will ack the device address. the device may return data or may leave the bus floating (which the system will interpret as a data value of 0xff) during the data periods. if the device does ack the device addre ss, the system should reset the internal address counter to force the atsha204 to ignore any partial input command that may have been sent. this can be accomplished by sending a write sequence to word address 0x00 (reset), followed by a stop condition. 2. if the device does not respond to the device address with an ack, then it may be asleep. in this case, the system should send a complete w ake token and wait t whi after the rising edge. the system may then send another read sequence, and, if synchronization ha s completed, the device will ack the device address. 3. if the device still does not respond to the device address with an ack, then it may be busy executing a command. the system should wait the longest t exec (max) and then send the read sequence, which will be acknowledged by the device . 7. electrical characteristics 7.1 absolute maximum ratings* operating t emperature ............................... ? 40c to +85c storage t emperature ................................ ? 65c to + 150c maximum o perating v oltage ........................................ 6.0v dc o utput c urrent ..................................................... 5.0ma voltage on any pin ............................... - 0.5v to (v cc + 0.5v) *notice: stresses beyond those listed under ?absolute maximum ratings? may cause permanent dam age to the device. this is a stress rating only, and functional operation of the device at these or any other condition beyond those indicated in the operational sections of this specification is not implied. exposure to absolute maximum rating conditions for extended periods may affect device reliability. 7.2 reliability the atsha204 is fabricated with the high reliability of the atmel cmos eeprom manufacturing technology. table 7 -1. eeprom reliability parameter min typical max units write e ndurance (each b yte at 2 5 c) 100,000 write c ycles data r etention (at 55c) 10 years data r etention (a t 35c) 30 50 years read e ndurance unlimited read c ycles atmel atsha204 [ datasheet ] 27 8740d ? crypto ? 3 /12 7.3 ac parameters ? all i/o interfaces figure 7 -1. ac timing diagram ? all i/o interfaces w ake noise suppression data comm t wlo t whi t lignore t hignore table 7 -2. ac parameters ? all i/o interfaces par ameter symbol direction min typ max unit notes wake l ow d uration t wlo to crypto authentication 60 - s sda can be stable in either high or low levels during extended sleep intervals . wake h igh d elay to d ata c omm. t whi to crypto authentication 2.5 ms sda should be stable high for this entire duration . high s ide g litch f ilter @ a ctive t hignore_a to crypto authentication 45 (1) ns pulses shorter than this in width will be ignored by the device , regardless of its state when active . low s ide glitch filt er @ active t lignore_a to crypto authentication 45 (1) ns pulses shorter than this in width will be ignored by the device , regardless of its state when active . high side glitch filter @ sleep t hignore_s to crypto authentication 15 (1) s pulses shorter than this in width will be ignored by the device when in sleep mode . low side glitch filter @ sleep t lignore_s to crypto authentication 15 (1) s pulses shorter than this in width will be ignored by the device when in sleep mode . watchdog r eset t watchdo g to crypto authentication 0.7 1. 3 1. 7 s max. time from wake until device is forced into sleep mode (s ee s ection 8.1.6 ). note: 1. these parameters are guaranteed through characterization, but not tested . atmel atsha204 [ datasheet ] 28 8740d ? crypto ? 3 /12 7.3.1 ac parameters ? single - wire interface figure 7 -2. ac timing diagram ? single - wire interface table 7 -3. ac parameters ? single - wire interface applicable from ta = ?40c to +85c, v cc = +2.0v to +5.5v, cl =100pf (unless otherwise noted) parameter symbol direction min typ max unit notes start pulse duration t start to crypto authentication 4.1 4.34 4.56 s from crypto authentication 4.6 6.0 8.6 s zero transmission high pulse t zhi to crypto authentication 4.1 4.34 4.56 s from crypto authentication 4.6 6.0 8.6 s zero t ransmission low pulse t zlo to crypto authentication 4.1 4.34 4.56 s from crypto authentication 4.6 6.0 8.6 s bit time (1) t bit to crypto authentication 37 39 - s if the bit time exceeds t timeout , then the atmel atsha204 may enter the sleep state. s ee section 5.3.1 for specific details. from crypto authentication 41 54 78 s turnaround delay t turnaround from crypto authentication 28 60 95 s the atmel atsha204 will initiate the first low - going transit ion after this time interval following the end of the last bit (t bit ) of the transmit flag . to crypto authentication 15 s after the atmel atsha204 transmits the last bit of a block, the system must wait this interval before sending the first bit of a flag . i/o timeout t timeout to crypto authentication 45 65 85 ms the atmel atsha204 may transition to the sleep state if the bus is inactive longer than this duration. see section 5.3.1 for specific details. note: 1 . t start , t zlo , t zhi , and t bit are designed to be compatible with a standard uart running at 230.4k baud for both transmit and receive. the uart should be set to seven data bi ts, no parity, and one stop bit . t start t zhi t zlo logic ? t start t bit logic 1 atmel atsha204 [ datasheet ] 29 8740d ? crypto ? 3 /12 7.3.2 ac parameters ? i 2 c interface figure 7 -3. i 2 c synchronous da ta timing scl sd a in sd a out t f t high t lo w t lo w t r t aa t dh t b uf t su .s t o t su .d a t t hd .d a t t hd .s t a t su .s t a table 7 -4. ac characteristics of i 2 c interface applicable over recommended operating range from t a = ?40c to + 85c, v cc = +2.0v to +5.5v, cl = 1 ttl gate and 100pf (unless otherwise noted) symbol parameter min max units f sck sck clock frequency 0 1 mh z sck clock duty cycle 30 70 percent t high sck high time 400 ns t low sck low time 400 ns t su.sta start setup time 250 ns t hd.sta start hold time 250 ns t su.sto stop setup time 250 ns t su.dat data in setup time 100 ns t hd.dat data in hold tim e 0 ns t r input rise time (1) 300 ns t f input fall time (1) 100 ns t aa clock low to data out valid 50 550 ns t dh data out hold time 50 ns t buf time bus must be free before a new transmission can start. (1) 500 ns notes: 1. values are based on character ization, but are not tested . 2. ac measurement conditions: y rl (connects between sda and v cc ): 2.0k ? (for v cc +2.0v to +5.0v) y input pulse voltages: 0.3v cc to 0.7v cc y input rise and fall times: 50ns input and output timing reference voltage: 0.5v cc atmel atsha204 [ datasheet ] 30 8740d ? crypto ? 3 /12 7.4 dc pa rameters ? all i/o interfaces table 7 -5. dc parameters ? all i/o interfaces parameter symbol min typ max unit notes ambient operating temperature t a -40 85 c power supply voltage v cc 2.0 5.5 v active power supply current i cc 1 ma 0 c ? +70 c, v cc = 3.3v - 3 ma -40c ? +85 c, v cc = 5.5v idle power supply current i idle 7 00 a when device is in idle mode, v cc = 3.3v , v sda & v scl < 0. 3 v or > > v cc -0. 3 sleep current i sleep 3 0 1 5 0 na when device is in sleep mode, v cc 3.6v, v sda & v scl < 0.3v or > v cc -0. 3, t a 55c 2 a when device is in sleep mode output low voltage v ol 0.4 v when device is in active mode, v cc = 2.5 ? 5.5v output low current i ol 4 ma when device is in active mode, v cc = 2.5 ? 5.5v, v ol = 0.4v 7.4.1 v ih and v il specifications the input voltage thresholds when in sleep or idle mode are dependent on the v cc level as follows: figure 7 -4. v ih and v il when in sleep or idle mode vih, vil when in sleep or idle mode 0.40 0.60 0.80 1.00 1.20 1.40 1.60 2.0 3.0 4.0 5.0 6.0 vcc vin vih vil atmel atsha204 [ datasheet ] 31 8740d ? crypto ? 3 /12 when the device is active (not in sleep or idle mode), the input voltage thresholds are different, depending on the sta te of ttlenable (bit three) within the i2c_address byte stored in the configuration zone of the eeprom. when a common voltage is used for the atsha204 v cc pin and the input pull - up resistor, then this bit should be set to a one, which permits the input thr esholds to track the supply as follows: figure 7 -5. v ih and v il ( device active , ttlenable = 1) ? all i/o interfaces vih, vil when ttlenable is 1 0.40 0.60 0.80 1.00 1.20 1.40 1.60 1.80 2.00 2.20 2.40 2.60 2.80 3.00 3.20 2.0 3.0 4.0 5.0 6.0 vcc vin vih vil if the voltage supplied to the v cc pin of the atsha204 is different from the system voltage to which the input pull - up resistor is connected, then the system designer may chose to set ttlenable to zero, which enables a fixed input threshold according to the following table. table 7 -6. v il and v ih ( device active , ttlenable = 0) ? all i/o interfaces parameter symbol min typ max unit notes input low voltage v il gnd - 0.5 0.5 v when device is active and ttlenable bit in configuration memory is zero ; o therwise , see above . input high voltage v ih 1.5 v cc + 0.5 v when device is active and ttlenable bit in configuration memory is zero ; o therwise , see above . atmel atsha204 [ datasheet ] 32 8740d ? crypto ? 3 /12 8. com mands 8.1 i/o blocks regardless of the i/o protocol being used (single - wire or i 2 c ), commands are sent to the device , and responses received from the device , within a block that is constructed in the following way: table 8 -1. i/o blocks byte # name meaning 0 count numbe r of bytes to be transferred to (or from) the device in the block, including count byte, packet bytes, and checksum bytes. the count byte should , therefore , always have a value of (n+1), where n is equal to the number of bytes in the packet plus the two ch ecksum bytes. thus, f or a block with one count byte, 50 packet bytes, and two checksum bytes, the count byte should be set to 53. the maximum size block (and value of count) is 84 bytes , and the minimum size block is four bytes. values outside this range w ill cause unpredictable operation . 1 to (n -2) packet command, parameters and data, or respo nse. see below for more details . n - 1, n checksum crc- 16 verification of the count and packet bytes. the crc polynomial is 0x8005. the in itial register value should be zero . a fter the last bit of the count and the packet have been transmitted , the internal crc register should have a value that matches the checksum bytes in the block. the first crc byte transmitted (n - 1) is the least - significant byte of the crc value, and so the last byte of the b lock is the m ost - significant byte of the crc . the atsha204 is designed in such a way that the count value in the input block should be consistent with the size requirements specified in the command parameters. if the count v alue is inconsistent with the command opcode and/or parameters within the packet, the atsha204 will respond in different ways, depending on the specific command. either the response may include an error indication or some input bytes may be silently ignore d. 8.1.1 command packets the command packet is broken down as shown in table 8 - 2 . table 8 -2. command packets byte # name meaning 0 opcode the command code ? see s ection 8.1.4 1 param1 the first parameter ? always present 2 -3 param2 the second parameter ? always present 4+ data optional remaining input data after the atsha204 receives all the bytes in a block, the device transitions to the busy state and attempts to execute the command. neither status nor result s can be read from the device when it is busy. during this time, the device ?s i/o interface ignores all sda transitions regardless of the i/o interface selected. the command execution delays are listed in section 8.1.4 . if insu fficient bytes are sent to the device when it is in one - wire mode, the device automatically transitions to the low - power sleep state after the t timeout interval. in i 2 c mode, the device continues to wait for the remaining bytes until the watchdog timer lim it, t watchdog , is reached or a start/stop condition is received by the device . in the individual command description tables below in sections 8.2 through 8.13 , the size column describes the number o f bytes in the parameter documented in each particular row. if the input block size for a particular command is incorrect, the device does not attempt to execute the command; instead, the device returns an error. atmel atsha204 [ datasheet ] 33 8740d ? crypto ? 3 /12 8.1.2 status/error codes the device does not have a dedicated status register, and so the output fifo is shared among status, error, and command results. all output from the device is returned to the system as complete blocks, which are formatted identically to input blocks: ? count ? packet ? 2 - byte crc afte r the device receives the first byte of an input command block, the system cannot read anything from the device until the system has sent all the bytes to the device . after wake and after execution of a command, there will be error, status, or result bytes in the device ?s output register that can be retrieved by the system. when the length of that block is four bytes, the codes returned are detailed below in table 8 -3 . some commands return more than four bytes when they execute successfully: the resulting packet description is listed in the command section below. crc errors are always returned before any other type of error. they indicate that some sort of i/o error occurred and that th e command may be resent to the device . if a command includes both parse and execution errors, there is no particular precedence enforced ? an execution error may occur before a parse error and/or the reverse. table 8 -3. status/error codes in 4 - byte blocks state description error/status description successful command execution 0x00 command executed successfully . checkmac miscompare 0x01 the checkmac command was properly sent to the device , but the input c lient r esponse did not match the expected value. parse e rror 0x03 command was properly received , but the length, command opcode, or parameters are illegal , regardless of the state (volatile and/or eeprom configuration) of the atsha204 . changes in the value of the command bits must be made before it is re - attempted. execution error 0x0f command was properly received , but could not be executed by the device in its current state . changes in the device state or the value of the command bits must be made before it is re - attempted. after wake , but prior to first command 0x11 indication that the atsha204 has recei ved a proper w ake token . crc or o ther communications error 0xff command was not properly received by the atsha204 , and should be re - transmitted by the i/o driver in the system . no attempt was made to parse or execute the command . atmel atsha204 [ datasheet ] 34 8740d ? crypto ? 3 /12 8.1.3 command opc odes, short descriptions, and execution times during parsing of the parameters and subsequent execution of a properly received command, the device will be busy and not respond to transitions on the pins. the interval during which the device will be busy va ries depending on the command and its parameter values, the state of the device , the environmental conditions, and other factors per the table below. table 8 -4. command opcodes, short descriptions , and execution times command opcode description typ. exec. time 1 , ms m ax. exec. time 2 , ms derivekey 0x1c derive a target key value from the target or parent key . 14 62 devrev 0x30 return device revision information . 0.4 2 gendig 0x15 generate a data protection digest from a random or input seed and a key . 11 43 hmac 0x11 calculate response from key and other internal data using hmac/sha -256 . 27 69 checkmac 0x28 verify a mac calculated on another atmel cryptoauthentication device . 12 38 lock 0x17 prevent further modifications to a zone of the device . 5 24 mac 0x08 calc ulate response from key and other internal data using sha - 256. 12 35 nonce 0x16 generate a 32 - byte random number and an internally stored nonce . 22 60 pause 0x01 selectively put just one device on a shared bus into the idle state . 0.4 2 random 0x1b gene rate a random number . 11 50 read 0x02 read four bytes from the device , with or without authentication and encryption . 0.4 4 updateextra 0x20 update bytes 84 or 85 within the configuration zone after the configuration zone is locked . 8 12 write 0x12 writ e 4 or 32 bytes to the device , with or without authentication and encryption . 4 42 notes: 1. typical execution times are representative of the duration to execute the command assuming no error conditions, fastest mode setting, no optional internal actions such a s limited use keys, and favorable environmental conditions. for best performance, delay for this interval and then start polling to dete rmine actual command completion . 2. maximum execution times are representative of the longest duration of a successful comm and execution with all mode and internal actions enabled under extended statistical and environmental conditions. execution time may extend beyond these values in extreme situations. in most but not all cases, failing commands will return relatively quickl y, often well be fore the typical execution time . atmel atsha204 [ datasheet ] 35 8740d ? crypto ? 3 /12 8.1.4 address encoding the read and write commands include a single address in param2 that indicates the memory to be accessed. all reads and writes are in units of four bytes (one word). the most - signific ant byte of a legal atsha204 address is always zero. all unused address bits should always be set to zero. the least - significant bits in the address describe the offset to the first word to be accessed within the block/slot, while the upper bits specify th e block/slot number per the table below: table 8 -5. address encoding (param2) zone byte 1 byte 0 unused unused block/slot offset config bits 0 ? 7 bits 5 ? 7 bits 3 ? 4 bits 0 ? 2 otp bits 0 ? 7 bits 4 ? 7 bit 3 bits 0 ? 2 data bits 0 ? 7 bit 7 bits 3 ? 6 bits 0 ? 2 within each zone, there are various access restrictions per the table below: table 8 -6. legal block /slot values zone legal block/slot (inclusive) notes config 0 -2 addresses below 16 ( b lock 0, o ffset 16) and above 87 ( b lock 2, o ffset 23) can never be written . addresses above 87 can never be read. both 4 - and 32- byte reads/writes are permitted otp 0 -1 when otpmode is read - only, all offsets in both blocks are available to use with 4- or 32 - byte reads . if otpmode is consumption, then writes are also permitted to all offsets . see s ection 2.1.3 if otpmode is legacy . data 0 -15 all offsets in all slots ava ilable for both read and write . 4 - byte access permitted on a particular slot only if slotcon fig.issecret is zero . in the table below , ?byte a ddress? is the byte address within the data zone for the first byte in the respective slot. because all reads and writes with the atsha204 are performed on a word (4 - byte or 32 - bit) basis, the word address in the table below should be used for the address parameter passed to the read and write commands. table 8 -7. data zone slots slot # byte address (hex) word address (hex) slot # byte address (hex) word address (hex) 0 0x0000 0x0000 8 0x0100 0x0040 1 0x0020 0x0008 9 0x0120 0x0048 2 0x0040 0x0010 10 0x 0140 0x0050 3 0x0060 0x0018 11 0x0160 0x0058 4 0x0080 0x0020 12 0x0180 0x0060 5 0x00a0 0x0028 13 0x01a0 0x0068 6 0x00c0 0x0030 14 0x01c0 0x0070 7 0x00e0 0x0038 15 0x01e0 0x007f atmel atsha204 [ datasheet ] 36 8740d ? crypto ? 3 /12 8.1.5 zone encoding the value in param1 controls which zone the command a ccesses. see s ection 2.1.2.1 , ? configuration zone locking ,? to obtain more information on what controls the ?locked? and ?unlocked? states for each zone. all other zone values are reserved , and should not be used. table 8 -8. zone encoding (param1) zone name param1 value size read write config 0 512 bits, 64 bytes, 2 s lots always available partially, when unlocked nev er when locked never encrypted otp 1 512 bits, 64 bytes, 2 s lots never when unlocked. always when locked, except in legacy mode. see s ection 2.1.3 all writeable when unlocked using write when locked, writ e permissions depend on otpmode see s ection 2.1.3 data 2 4096 bits, 512 bytes, 16 slo ts never when unlocked. otherwise , controlled by issecret and encryptread. all writeable when unlocked when locked, w rites controlled by writeconfig 8.1.6 watchdog failsafe a watchdog counter starts within the device after the atsha204 receives a wake token. a fter t watchdog , the device enters sleep mode, regardless of whether some i/o transmission or command execution is in progress. there is no way to reset the counter other than to put the device into sleep or idle mode and then wake it up again. the watchdog timer is implemented as a failsafe mechanism so that no matter what happens on either the system side or inside the device , including any i/o synchronization issue, power consumption will fall to the ultra - low sleep level automatically. the device resets the values stored in the sram and internal status registers when it transitions to the sleep state. however, if the device is explicitly put into the idle mode through the appropriate i/o sequence, the device retains the contents of the two sram registers (tempkey and rng seed). normally, all command s equences must complete within t watchdog if they require state that is stored in the sram registers. the system software can use this idle mode mechanism to implement a longer command sequence than can be comp leted during a single watchdog interval. atmel atsha204 [ datasheet ] 37 8740d ? crypto ? 3 /12 8.2 checkmac command the checkmac command calculates a mac response that would have been generated on a cryptoauthentication device and compares that with an input value. it returns a boolean to indicate th e success or failure of the comparison. prior to running this command, the nonce and/or gendig commands may have been optionally run to create a key or nonce value in tempkey. the input mode parameter determines the source of the ?key? (the first 32 bytes of the sha message) and ?challenge/nonce? (the second 32 bytes of the sha message). if the comparison matches, then the target eeprom slot value may be copied into tempkey. if keyid is even, then the target slot is keyid+1, else the target slot is keyid. f or the copy to take place, the mode parameter to checkmac must have a value of 0x01 and slotconfig.readkey for the target key must be zero. when checkmac is loaded in this manner, it will not be retained when the device enters the i dle state table 8 -9. input paramete rs name size notes opcode checkmac 1 0x28 param1 mode 1 bit 0: if zero, the second 32 bytes of the sha message are taken from the input clientchal parameter. if one, the second 32 bytes of the message are taken from tempkey . bit 1: if zero, use key[keyi d] in first sha block. if one, use tempkey . bit 2: if mode:0 or mode:1 are set, then the value of this bit must match the value in tempkey.sourceflag or the command will return an error. bit 5: if one, use 64 bits of otp zone in cal culation. if zero, use 6 4 zeros . bits 3 - 4 and 6- 7: must be zero. param2 keyid 2 which internal key is to be used to generate the respons e. all but bits 0:3 are ignored . data1 clientchal 32 challenge sent to client. if mode:0 is one, then the value of this parameter will be igno red (though these 32 bytes must still appear in the input stream) . data2 clientresp 32 response generated by the client . data3 otherdata 13 remaining constant data needed for response calculation . table 8 -10. output parameter name size notes result 1 returns a sin gle byte with a value of zero if clientresp matches the internally computed dig est, one if there is a mismatch . the message that will be hashed with the sha - 256 algorithm consists of the following information: 32 bytes key[keyid] or tempkey (depending on mode) 32 bytes clientchal or tempkey (depending on mode) 4 bytes otherdata[0:3] 8 bytes otp[0:7] (or 0s depending on mode) 3 bytes otherdata[4:6] 1 byte sn[8] 4 bytes otherdata[7:10] 2 bytes sn[0:1] 2 bytes otherdata[11:12] atmel atsha204 [ datasheet ] 38 8740d ? crypto ? 3 /12 8.3 derivekey com mand the device combines the current value of a key with the nonce stored in tempkey using sha - 256, and places the result into the target key slot. slotconfig[targetkey]. bit13 must be set or derivekey will return an error. if slotconfig[targetkey].bit12 i s zero, the source key that will be combined with tempkey is the target key specified in the command line (roll key operation). if slotconfig[targetkey].bit12 is one, the source key is the parent key of the target key, which is found in slotconfig[targetke y].writekey (create key operation). prior to execution of this command, the nonce command must have been run to create a valid nonce in tempkey. depending on the state of bit two of the input mode, this nonce must have been created with the internal random number generator, or it must have been fixed. if slotconfig[targetkey].bit15 is set, an input mac must be present and have been computed as: sha - 256(parentkey, opcode, param1, param2, sn[8], sn[0:1]) where the parentkey id is always slotconfig[targetkey ].writekey. if slotconfig[targetkey].bit12 or slotconfig[targetkey].bit15 is set and slotconfig[parentkey].singleuse is also set, derivekey returns an error if useflag[parentkey] is 0x00. derivekey ignores singleuse and useflag for the target key if slotco nfig[targetkey].bit12 and slotconfig[targetkey].bit15 are both zero. for slots 0 - 7 only, if input parsing and the optional mac check succeed, useflag[targetkey] gets set to 0xff and updatecount[targetkey] is incremented. if updatecount currently has a valu e of 255, it wraps to zero. if the command fails for any reason, these bytes are not updated. the value of updatecount may be corrupted if power is interrupted during the execution of derivekey. note: if the source and target key are the same, there is a risk o f permanent loss of the key value if power is interrupted during the write operation. if the configuration bits permit it, the key slot may be recovered using an authenticated and encrypte d write based on the parent key . table 8 -11. input parameters name size notes opcode derivekey 1 0x1c param1 random 1 bit 2: the value of this bit must match the value in tempkey.sourceflag or the command will return an error . bits 0:1, 3:7: must be zero . param2 targetkey 2 key slot to be written . data mac 0 or 32 optional mac us ed to validate operation . table 8 -12. output parameter name size notes success 1 upon successful completion, the atsha204 returns a value of zero . atmel atsha204 [ datasheet ] 39 8740d ? crypto ? 3 /12 the key written to the target slot is the result of a sha - 256 of the following message: 32 bytes target or parent key (depending on slotconfig bit12) 1 byte opcode 1 byte param1 2 bytes param2 1 byte sn[8] 2 bytes sn[0:1] 25 bytes zeros 32 bytes tempkey.value the data flow for this command is shown graphically in the figure below: figure 8 -1. data flow for derivekey command match parent key t arget key sha (auth) input mac sha (derive) mode source key nonce atmel atsha204 [ datasheet ] 40 8740d ? crypto ? 3 /12 8.4 devrev command devrev command returns a single four - byte word representing the revision number of the device. software should not depend on this value as it may change from time to time. table 8 -13. input parameters name size notes opcode devrev 1 0x30 param1 mode 1 must be zero . param2 - 2 must be zero . data - 0 - table 8 -14. output parameters name size notes success 4 the current device revision number . atmel atsha204 [ datasheet ] 41 8740d ? crypto ? 3 /12 8.5 gendig command uses sha - 256 to combine a stored value with t he contents of tempkey, which must have been valid prior to the execution of this command. the stored value can come from one of the data slots, either of the otp pages, either of the first two pages of the configuration zone, or retrieved from the hardwar e transport key array. the resulting digest is retained in tempkey, and can be used in one of three ways: 1. it can be included as part of the message used by the mac, checkmac, or hmac commands. because the mac response output incorporates both the data used in the gendig calculation and the secret key from the mac command, it serves to authenticate the data stor ed in the data and/or otp zones . 2. a subsequent read or write command can use the digest to provide authentication and/or confidentiality for the data, in which case it is known as a data protectio n digest . 3. you can use this command for secure personalization by using a value from the transport key array. the resulting data protection digest would th en be used by the write command . if zone is two (data) a nd keyid is 15, the gendig command sets tempkey.gendata to one and tempkey.keyid to the input keyid; otherwise, tempkey.gendata is set to zero. regardless of how the resulting digest is computed, it can never be read from the device . if tempkey.valid is invalid, this command returns an error. upon command completion, the tempkey.valid bit is set, indicating that a digest has been loaded and is ready for use. the tempkey.valid bit is cleared when the next command is executed. see section 2.2 for more details. for all keyid values less than 0x8000, the device uses the least - significant four bits of keyid to determine the slot number from which to retrieve the key value from the data zone of the eeprom. keyid values above 0x8000 r eference keys stored in the masks of the design. in any event, all 16 bits of keyid as input to the device are used as param2 in the sha - 256 calculation. if the zone parameter points to the configuration zone, then this command returns an error if the conf iguration zone is unlocked. when the key specified on input to gendig has the checkonly bit set, gendig can be used to generate ephemeral keys matching those generated on client cryptoauthentication device s using the derivekey command. keys that have the c heckonly bit set represent situations in which the device is acting as a host. in this case, the opcode and parameter bytes that would normally be included in the sha calculation are replaced with bytes from the input stream. table 8 -15. input parameters name size no tes opcode gendig 1 0x15 param1 zone 1 if 0x00 (config): use keyid to specify either the first (keyid=0) or second (keyid = 1) 256- bit block of the configuration zone . if 0x01 (otp): use keyid to specify either the first or second 256 - bit block of the ot p zone . if 0x02 (data): keyid specifies a slot in the data zone or a transport key in the hardware array . all other values are reserved and must not be used . param2 keyid 2 identification number of the key to be used, or selection of which otp block . dat a otherdata 4 or 0 4 bytes of data for sha calculation when using a checkonly key; otherwise ignored . table 8 -16. output parameter name size notes success 1 upon successful execution, the atmel atsha204 returns a value of zero . atmel atsha204 [ datasheet ] 42 8740d ? crypto ? 3 /12 if zone is data and slotconfig[keyi d].checkonly is one, the sha - 256 message body used to create the resulting new tempkey consists of the following bytes: 32 bytes data.slot[keyid] 4 bytes otherdata 1 byte sn[8] 2 bytes sn[0:1] 25 bytes zeros 32 bytes tempkey.value in all othe r cases, the message use to create tempkey is as follows: 32 bytes config[keyid] or otp[keyid] or data.slot[keyid] or transportkey[keyid] 1 byte opcode 1 byte param1 2 bytes param2 1 byte sn[8] 2 bytes sn[0:1] 25 bytes zeros 32 bytes tempk ey.value atmel atsha204 [ datasheet ] 43 8740d ? crypto ? 3 /12 8.6 hmac command computes a hmac/sha - 256 digest of a key stored in the device , a challenge, and other information on the device . the output of this command is the output of the hmac algorithm computed over this key and message. if the message includes the serial number of the device , the response is said to be diversified. the normal command flow to use this command is as follows: 1. run nonce command to load input challenge and optionally combine it with a generated random number. the result of this operation is a nonce stored internally on the device . 2. optionally run gendig command to combine one or more stored eeprom locations in the device with the nonce. the result is stored internally in the device . 3. run this hmac command to combine the output of steps one (and step two if desired) with an eeprom key to generate an output response . step two addresses multiple use models. if the data in the eeprom is a key, gendig has the effect of authenticating the challenge with multiple secret key s. alternatively, if the contents of the slot are data (which does not have to necessarily even be secret), gendig has the effect of authenticating the value stored in that location. table 8 -17. input parameters name size notes opcode hmac 1 0x11 param1 mode 1 cont rols which fields within the device are used in the message . param2 keyid 2 which key is to be used to generate the response . bits 0:3 only are used to select a slot but all 16 bits are used in the hmac message . data - 0 - table 8 -18. output parameter name size no tes response 32 hmac digest the hmac digest is computed using the key at keyid as the hmac key over a message consisting of the following information: 32 bytes zeros 32 bytes tempkey 1 byte opcode (always 0x11) 1 byte mode 2 bytes keyid 8 b ytes otp[0:7] (or zeros, see table 8 -19) 3 bytes otp[8:10] (or zeros, see table 8 -19 ) 1 byte sn[8] bits (never zeroed out) 4 bytes sn[4:7] bits (or zeros, see tabl e 8- 19) 2 bytes sn[0:1] (never zeroed out) 2 bytes sn[2:3] (or zeros, see table 8 -19) atmel atsha204 [ datasheet ] 44 8740d ? crypto ? 3 /12 see the nist hmac specification for a complete description of how the various digests are calculated using sha - 256, the hmac key, and a ppropriate padding. see http://csrc.nist.gov/publications/fips/fips198/fips - 198a.pdf . the padding is part of the sha - 256 message (see section 3.1 ). h mac is a construct that sits on top of sha -256. table 8 -19. mode encoding bits meaning 7 must be zero . 6 if set, include the 48 bits sn[2 :3] and sn[4:7] in the message . otherwise, the corresponding message bits are set to zero . 5 include the first 64 otp bits (otp[ 0] through otp[7]) in the message . otherwise, the correspondin g message bits are set to zero . if mode[4] is set, the va lue of this mode bit is ignored . 4 include the first 88 otp bits (otp[0] t hrough otp[10]) in the message . otherwise, the corresponding m essage bits are set to zero . 3 must be zero . 2 the value of this bit must match the value in tempkey.sourceflag or the command will return an erro r. 0 -1 must be zero . atmel atsha204 [ datasheet ] 45 8740d ? crypto ? 3 /12 8.7 lock command write either lockconfig or lockvalue to 0x ff, thereby changing the permissions in the designated zone. this command fails if the designated zone is already locked. prior to locking the device , the atsha204 uses the crc - 16 algorithm to generate a summary digest of the designated zone(s). the calcul ation is made identically to the crc computed over the input and output blocks. ? for the configuration zone, the crc is calculated over all 88 bytes . ? for the data and otp zones, their contents are concatenated in that order to create the input to the crc al gorithm . if the input summary does not match that computed on the device , an error is returned and the personalization process should be repeated. table 8 -20. input parameters name size notes opode lock 1 0x17 param1 zone 1 bit 0: zero for c onfig zone, 1 for d ata and otp zones . bits 1 - 6: must be zero. bit 7: if one, the check of the zone crc is ignored and the zone is locked , regardless of the state of the memory. atmel does not recommend using this mode . param2 summary 2 summary of the designated zones, or shou ld be 0x0000 if zone[7] is set . data - 0 - table 8 -21. output parameter name size notes success 1 upon successful execution, the atmel atsha204 returns a value of zero . atmel atsha204 [ datasheet ] 46 8740d ? crypto ? 3 /12 8.8 mac command computes a sha - 256 digest of a key stored in the device , a ch allenge, and other information on the device . the output of this command is the digest of this message. if the message includes the serial number of the device , the response is said to be diversified. the normal command flow to use this command is as follo ws: 1. run nonce command to load input challenge and optionally combine it with a generated random number. the result of this operation is a nonc e stored internally on the device . 2. optionally run gendig command to combine one or more stored eeprom locations in the device with the nonce. the result is stored internally in the device . this capability permits two or more keys to be used as part of the response generation . 3. run this mac command to combine the output of step one (and step two if desired) with an eepr om key to generate an output response (or digest) . alternatively, data in any slot (which does not have to necessarily even be secret) can be accumulated into the response through the same gendig mechanism. this has the effect of authenticating the value s tored in that location. table 8 -22. input parameters name size notes opcode mac 1 0x08 param1 mode 1 controls which fields within the device are used in the message . param2 keyid 2 which internal key is to be used to generate the response . bits 0:3 only are used t o select a slot but all 16 bits are used in the sha - 256 message. data challenge 0 or 32 input portion of message to be digested, ignored if mode:0 is one . table 8 -23. output parameter name size notes response 32 sha - 256 digest the message that will be hashed with the sha - 256 algorithm consists of the following information: 32 bytes key[keyid] or tempkey ( s ee table 8 -24 ) 32 bytes challenge or tempkey ( see table 8 -24) 1 byte opcode (always 0x08) 1 byte mode 2 bytes param2 8 bytes otp[0:7] (or zeros, see table 8 -24) 3 bytes otp[8:10] (or zeros, see table 8 -24 ) 1 byte sn[8] bits (never zeroed out) 4 bytes sn[4:7] bits (or zeros, see table 8 - 24) 2 bytes sn[0:1] (never zeroed out) 2 bytes sn[2:3] (or zeros, see table 8 -24) atmel atsha204 [ datasheet ] 47 8740d ? crypto ? 3 /12 table 8 -24. mode encoding bits meaning 7 must be zero . 6 if set, include the 48 bits sn[2 :3] and sn[4:7] in the message . other wise, the corresponding message bits are set to z ero . 5 include the first 64 otp bits (otp[0] through otp[7]) in the message . otherwise, the correspondi ng message bits are set to zero . if mode[4] is set, the va lue of this mode bit is ignored . 4 include t he first 88 otp bits (otp[0] through otp[10]) in the message . otherwise, the correspondi ng message bits are set to zero . 3 must be zero . 2 if either mode:0 or mode:1 are set, mode:2 must match the value in tempkey.sourceflag or t he command will return an error . 1 if zero, the first 32 bytes of the sha message are loa ded from one of the data slots . if one, the first 32 bytes are filled with tempkey . 0 if zero, the second 32 bytes of the sha message are taken fro m the input challenge parameter . if one, th e second 32 bytes are filled with the value in tempkey. this mode is recommended for all use . atmel atsha204 [ datasheet ] 48 8740d ? crypto ? 3 /12 8.9 nonce command this command generates a nonce for use by a subsequent gendig, mac, hmac, read, or write command by combining an internally generated random number with an input value from the system. the resulting nonce is stored internally in tempkey and the generated random number is returned to the system. the input value is designed to prevent replay attacks ag ainst the host it must be externally generated by the system and passed into the device using this command. it may be any value that changes consistently, such as a nonvolatile counter, current real time of day, and so on, or it can be an externally gene rated random number. to provide a nonce value for subsequent crypto commands, the input number and output random number are hashed together per the information listed below. the resulting digest (nonce) is always stored in the tempkey register, tempkey.val id is set, and tempkey.sourceflag is set to ?rand.? the nonce can be used by a subsequent gendig, read, write, hmac, or mac command ? thus, the system must externally compute this digest value and store it externally to complete the execution of those comm ands. alternatively, this command can also be run in a pass - through mode if a fixed nonce is required for subsequent commands. in this case, the input value must be 32 bytes long, and it is passed directly to tempkey without modification. no sha - 256 calcul ation is performed, and tempkey.sourceflag is set to ?input.? the nonce value in tempkey may not be used with read or write commands. if operated in this mode and with a repeated input number value, the device provides no protection against replay attacks. prior to the configuration section being locked, the random number generator produces a value of 0xff ff 00 00 ff ff 00 00 to facilitate testing. this test value is combined with the input value in the manner described above. table 8 -25. input parameters name size notes opode nonce 1 0x16 param1 mode 1 controls the mechanism of the internal random number generator and seed update . param2 zero 2 must be 0x0000 . data numin 20,32 input value from system . table 8 -26. output parameter name size notes randout 1 or 32 the outp ut of the random number generator or a single byte with a value of zero if mode[0:1] is three . if mode[0:1] is zero or one, the input numin parameter must be 20 bytes long, and the sha - 256 message body used to create the nonce stored internally in tempk ey consists of the following: 32 bytes randout 20 bytes numin from input stream 1 byte opcode (always 0x16) 1 byte mode 1 byte lsb of param2 (should always be 0x00) atmel atsha204 [ datasheet ] 49 8740d ? crypto ? 3 /12 upon completion of the command, tempkey.sourceflag is set to ?rand.? if mode [0:1] is three, this command operates in pass - through mode, the input parameter (numin) must be 32 bytes long, and tempkey is loaded with numin. no sha - 256 calculation is performed, no data is returned to the system, and tempkey.sourceflag is set to ?input .? if mode[0:1] is one, the automatic seed update is suppressed. see section 3.4.2 for more details. table 8 -27. mode encoding bits meaning 2 -7 must be zero . 0 -1 0: combine new random number with numin, store in tempkey. automatically u pdate eeprom seed only if necessary prior to random number generation. r ecommended for highest security . 1: combine new random number with numin, store in tempkey. generate rando m number using existing eeprom seed, do not update eeprom seed . 2: invalid 3: operate in pass - through mo de and write tempkey with numin. atmel atsha204 [ datasheet ] 50 8740d ? crypto ? 3 /12 8.10 pause command all device s on the bus for which the configuration selector byte does not match the input selector parameter will go into the idle state. this com mand is used to prevent bus conflicts in a system that includes multiple atsha204 device s sharing the same bus. this command differs from the i dle flag/sequence in that individual device s on the single pin bus may be selected to go into the idle state, as opposed to the i dle flag which causes all the cryptoauthentication devices on the bus into the idle state. if the eeprom selector byte does not match the input selector parameter, the device will immediately go to the idle state and no result information will be available. if the input selector parameter does match the configuration selector byte, the device returns a success code of 0x00. the pause command cannot be used to put the device s into the sleep state. table 8 -28. input parameters name size notes opode pau se 1 0x01 param1 selector 1 all device s that do not match this value go to idle state . param2 zero 2 must be 0x0000 data - 0 - table 8 -29. output parameter name size notes success 1 if the command indicates that some other device should idle, the atmel at sha204 returns a value of 0x00 . if this device goe s to idle, no value is returned . atmel atsha204 [ datasheet ] 51 8740d ? crypto ? 3 /12 8.11 random command this command generates a random number for use by the system. random numbers are generated through a combination of the output of a hardware ra ndom number generator and an internal seed value stored in the eeprom or sram. the external system may choose to update the internally stored eeprom seed value prior to the generation of the random number as part of the execution of the nonce or random com mand, though the endurance limitations of the eeprom limit the number of times that this update can be performed. after the endurance limit has been reached, attempts to update the eeprom seed return an error. the random command does not provide a mechanis m to integrate an input number with the internal stored seed. if this functionality is desired, the system should use the nonce command and ignore the generated nonce. prior to the configuration section being locked, the random number generator produces a value of 0xff, 0xff, 0x00, 0x00, 0xff, 0xff, 0x00, 0x00 to facilitate testing. note: the same internally stored seeds are used for both the nonce and random commands. use of mode=0 ensures that the eeprom is updated, if necessary. table 8 -30. input parameters name size no tes opode random 1 0x1b param1 mode 1 controls the mechanism of the internal random n umber generator and seed update . param2 zero 2 must be 0x0000 data - 0 - table 8 -31. output parameter name size notes randout 32 the output of the random number generator . table 8 -32. m ode encoding bits meaning 1 -7 must be zero . 0 0: automatically update eeprom seed only if necessary pri or to random number generation r ecommended for highest security . 1: generate random number using existing eeprom seed; do not update eeprom seed . atmel atsha204 [ datasheet ] 52 8740d ? crypto ? 3 /12 8.12 read command reads words (one 4 - byte word or an 8 - word block of 32 bytes) from one of the memory zones of the device . the data may optionally be encrypted before being returned to the system. see also section 8.1.5 , ? zone encoding ,? and section 8.1.4, ? address encoding ,? for data zone byte and word addressing information. if reading from a slot in which slotconfig.encryptread is set, the gendig command must have been run prior to the execution of this command to generate the key that will be used for encryption. the input nonce to gendig must have been a random number, and the key specified in slotconfig.readkey must have been used in the gendig calculation. the device encrypts data to be read by xoring each byte read from the eeprom with the corresponding byte from tempkey. encrypted reads of the configuration and/or otp zones are not permitted. the byte addresses to be read should be divi ded by four (drop the least - significant two bits) before being passed to the device . if 32 bytes are being read, the least - significant three bits of the input address are ignored. addresses beyond the end of the specified zone result in an error. the follo wing restrictions apply to the three zones: config the words within this zone are always readable using this command, regardless of the value of lockconfig. see section 2.1.1, as some bytes are unreadable under any circumstances, and any attempt to read t hese bytes result in an error. otp if the otp zone is unlocked, this command returns an error. once locked, if otpmode is set to a non - zero value and the address points to either word zero or one, then the command also returns an error. otherwise, the cor responding word within the otp zone is returned in the clear. if otpmode is legacy, then only four byte reads are permitted. data if the data zone is unlocked, this command returns an error. otherwise, the values within the corresponding slotconfig word c ontrol access to the data slot. if slotconfig.issecret is set and a four byte read is attempted, the device returns an error. if encryptread is set, this command encrypts the data as specified above. if issecret is set and encryptread is clear, this comma nd returns an error. if issecret is clear and encryptread is clear, this command returns the desired slot in the clear. table 8 -33. input parameters name size notes opcode read 1 0x02 param1 zone 1 bits 0 and 1: select among config, otp, or data. see section 8.1.5 . bits 2 - 6: must be zero. bit 7: if one, 32 bytes are read; otherwise four bytes are read. must be zero if reading from o tp zone . param2 address 2 address of first word to be read within the zone. see section 8.1.4 . data - 0 - table 8 -34. output parameter name size notes contents 4 or 32 the contents of the specified memory location . atmel atsha204 [ datasheet ] 53 8740d ? crypto ? 3 /12 if reading the data zone and the encryptread bit is set in the corresponding slotconfig word, the following actions are taken to encrypt the data: all of the tempkey register bits must be properly set as follows, or this command returns an error: tempkey.valid == 1 tempkey.gendata == 1 tempkey.keyid == slotconfig.readkey tempkey.sourceflag == ?rand? xor the data from th e memory zone with tempkey. return as ?contents.? atmel atsha204 [ datasheet ] 54 8740d ? crypto ? 3 /12 8.13 updateextra command this command is used to update the values of the two ?extra? bytes within the configuration zone (location 84 and 85) after t he configuration zone has been locked. if the mode parameter indicates userextra at address 84: if the current value in userextra (byte 84 of configuration zone) is zero, then updateextra writes this byte with the ls byte of newvalue and returns success. if the current value in userex tra is non - zero, the command returns an execution error. if the mode parameter indicates selector at address 85: if selectormode (byte 19 of the configuration zone) is non - zero and selector (byte 85 of the configuration zone) is zero, this command will wri te selector with the ls byte of newvalue and return success. once written to a non - zero value, it is then locked against further updating. if selectormode has a value of zero, indicating that no check of the current selector should be made, this command al ways updates selector and always succeeds. table 8 -35. input parameters name size notes opode updateextra 1 0x20 param1 mode 1 bit 0: if zero, update config byte 84. if one, update config byte 85. bits1 - 7: must be zero param2 newvalue 2 lsb: v alue to option ally be written to location 84 or 85 in configuration zone . msb: must be 0x00 . data - 0 - table 8 -36. output parameter name size notes success 1 if the memory byte was updated, this com mand returns a value of 0x00 otherwise , it returns an execution error . atmel atsha204 [ datasheet ] 55 8740d ? crypto ? 3 /12 8.14 write command writes either a one 4 - byte word or an 8 - word block of 32 bytes to one of the eeprom zones on the device . depending on the value of the writeconfig byte for this slot the data may be required to be encrypted by the system prior to be ing sent to the device . the following restrictions apply to writes within zones using this command: config if t he config zone is locked or zone:6 is set, this command returns an error. otherwise the bytes are written as requested. any attempt to write any byte for which writes are permanently prohibited (per section 2.1.1 ) results in a command error with no modifications to the eeprom. otp if the otp zone is unlocked, all bytes can be written with this command. if the otp zone is locke d and the otpmode byte is read - only or l egacy, then this command returns an error. otherwise, otp mode should be c onsum ption and this command sets to zero those bits in the otp zone that correspond to the zero bits in the i nput par ameter v alue. when the otp zone is locked, encrypted writes to it are never permitted regardless of otpmode. data if the d ata zone is unlocked, all bytes in all zones can be written with either plain text or encrypted data. after the data zone is locked, the values within the writeconfig bytes control access to the data slots. if the writeconfig bits for this slot are set to ?a lways?, the input data should be passed to the device in the clear. if bit:14 of slotconfig is set to one , the input data should be encrypted and an input mac calculated. four byte wr ites are only permitted in the d ata and otp zones if all four of the following conditions are met: ? slotconfig.issecret must be zero . ? slotconfig.writeconfig must be ?always . ? ? the input data must not enc rypted . ? the d ata/otp zones must be locked . four byte writes will return an error under all other circumstances. the least significant three bits of param2, address[0:2], indicate the word within the block, or are ignored if an entire 32 byte block is bein g written. address[3:6] contains the slot number for writes to the d ata zone, or the block number for the config and otp zones. address values beyond the size of the specified zone result in the command returning an error. any a ttempt to write the otp and/ or d ata zones prior to the configuration section being locked results in the device returning an error code. 8.14.1 input data encryption the input data may be encrypted to prevent snooping on the bus during personalization or system operation. the system should encrypt the data by xor?ing the plain text with the current value in tempkey. upon receipt the device will xor the input data with tempkey to restore the plain text prior to writing to the eeprom. whenever the input data is encrypted an authorizing input mac is always required w hen writing the data zone. this mac is computed as: sha - 256(tempkey, opcode, param1, param2, sn[8], sn[0:1], <25 bytes of 0?s>, plaintextdata ) prior to loc king of the otp/data zones, zone:6 is used to indicate to the device whethe r or not the input data is encrypted. after loc king of the otp/data zones, zone:6 is ignored and only bit 14 of the slotconfig corresponding to the slot being written is used to determine whether or not the input data is encrypted. if data encryption is in dicated, tempkey must be valid prior to this command being called, it must be the result of gendig. specifically, this means that tempkey.valid and temp key.gendig must both be set to one . prior to data locking, any key can be used to generate tempkey. afte r locking, the last slot used by gendig for tempkey creation and stored in tempkey.keyid must match that in slotconfig.writekey and the random number generator must have been used to originally ge nerate tempkey prior to gendig. atmel atsha204 [ datasheet ] 56 8740d ? crypto ? 3 /12 table 8 -37. input parameters name size notes opcode write 1 0x12 param1 zone 1 bits 0 and 1: select among config, otp or data. see section 8.1.5 . bits 2 - 5: must be zero. bit 6: if one, the input data must be encrypted. must be zero if data/otp zones are locked . bi t 7: if one, 32 bytes will be written; otherwise, four bytes are written . param2 address 2 address of first word to be written within the zone. see section 8.1.4 . data_1 value 4 or 32 information to be written to the zone; ma y be encrypted . data_2 mac 0 or 32 message authentication code to validate address and da ta . ignored if zone is unlocked . table 8 -38. output parameter name size notes success 1 upon successful completion, the atmel atsha204 returns a value of zero . atmel atsha204 [ datasheet ] 57 8740d ? crypto ? 3 /12 9. compatibility the atsha204 is designed to be upwards compatible with the at88sa102s for field operation. most systems designed to use the at88sa102s in client devices will work perfectly with the atsha204 in the client devices without any mo dification to the host system software or hardware. host systems that utilize the at88sa10hs host device will also interoperate properly with the atsha204 client device in place of a previously used at88sa102s client. however, the at88sa10hs itself cannot be replaced with the atsha204 without software modifications. with the appropriate software updates, the atsha204 can implement all the functions of an at8810hs host device and continue to properly communicate with client at88sa102s device s. for compatibil ity with the at88sa102s, the following values should be written to the memory of the atsha204: 1. during configuration, otpmode should be set to legacy to hide the values of the first 64 bits of the otp section, which contain a secret in the atmel at88sa102s . 2. the same secret and status information that would have been written to the first 88 fuse bits of the atmel at88sa102s should be written to the first 88 bits of the ot p section on the atmel atsha204 . 3. otp bits 88 through 127 should be written with copies of the values stored in sn[4:8] within the configuration section of the atmel atsha204 device . the read command on legacy systems will always use the values in the otp section while the atmel atsha204 always uses the values in the configuration zone during t he computation of cryptographic results . 4. the key slot identified by the least significant four bits of the atmel at88sa102s keyid assigned to a particular customer should be loaded with the at mel - provided value for that key . 5. the slotconfig bits for the key slot identified in step four should be set to: checkonly=0, singleuse=0, encryptread= 0, issecret=1, writeconfig=1000 . the following compatibility exceptions apply: ? those atmel at88sa102s systems using the burnfuse command on the client device cannot be r eplaced with the atmel atsha204, as the corresponding command is not available on the atmel atsha204. the same capability is implemented with the write command, but system softw are modifications are necessary . ? those atmel at88sa102s systems in which the sy stem software reads and depends on a fixed value for the device revision number (revnum at rom address one) will find a differe nt value in the atmel atsha204 . note: this value is not guaranteed to be identical for all atmel at88sa102s device s . ? systems including multiple atmel at88sa102s and/or atmel at88sa10hs device s on a shared single - wire bus cannot be replaced with the atmel atsha204, as the pau se command operates differently . ? t he key diversification strategy implemented by the atmel atsha204 (when operating as a host) is different from the similar strategy used by the atmel at88sa10hs. the atmel atsha204 can be used as a host authentication device for atmel atsha204 clients that include diversified keys, but those clients will not work interchangeabl y with at mel at88sa102s clients . ? because of the difference in the nonvolatile memory technology and size, the secure personalization mechanism is different on the atmel atsha204 as compared to the atmel at88sa10hs and atmel at88sa102s. users will need to modify the ir manufacturing processes and proce dures accordingly . ? the atmel atsha204 cannot replace a client atmel at88sa100s device used for batteries and other self - powered systems . atmel atsha204 [ datasheet ] 58 8740d ? crypto ? 3 /12 10. mechanical 10.1 pin out the device is offered in multiple packages: 3 - lead sot23, 8- lead soic, 8- lead tssop, 8 - pad udfn and a 3- lead contact package intended for mechanical, not soldered, connection. the pin outs are as follows: table 10 -1. package pinouts name sot23 - 3ld soic - 8ld, tssop - 8ld, udfn - 8 pad 3- lead contact sda 1 5 1 scl ? 6 - v cc 2 8 3 gnd 3 4 2 nc ? 1, 2, 3, 7 - 10.2 wiring configuration for single - wire interface using the single - wire interface allows the connection of the atsha204 to a host using only a single pin (sda) to transfer data in both directions. this interface does not use the scl pin. in this configuration, no bypass capacitor is required to connect the device to the system. to prevent forward biasing the internal diode and drawing current across power planes in the system, the resistor pull -up on the sda pin should either be connected to the same supply that is connected to the v cc pin or to a lower voltage rail. if the signal levels for sda are different from the v cc voltage, consult the parametric specifications section of this document to ensure that the signal levels a re such that excessive leakage current will be minimized when in sleep modes. this situation might occur if the atsha204 device is physically distant from the bus master device and the supply voltage for the bus master is different from the supply voltage for the atsha204. figure 10 -1. three - wire configuration for single - wire interface atmel atsha204 [ datasheet ] 59 8740d ? crypto ? 3 /12 11. package drawings 11.1 3 -lead sot23 title dra wing no. gpc rev . package drawing contact: packagedrawings@atmel.com 3ts1 tbg a 3ts1, 3-lead, 1.30mm bod y , plastic thin shrink small outline package (shrink sot) 1 1/5/08 common dimensions (unit of measure = mm) symbol min nom max note a 0.89 - 1.12 a 1 0.01 - 0.10 a 2 0.88 - 1.02 d 2.80 2.90 3.04 1,2 e 2.10 - 2.64 e 1 1.20 1.30 1.40 1,2 l 1 0.54 ref e1 1.90 bsc b 0.30 - 0.50 3 1. dimension d does not include mold flash, protrusions or gate burrs. mold flash, protrusions or gate burrs shall not exceed 0.25mm per end. dimension e1 does not include interlead flash or protrusion. interlead flash or protrusion shall not exceed 0.25mm per side. 2. the package top may be smaller than the package bottom. dimensions d and e1 are determined at the outermost extremes of the plastic body exclusive of mold flash, tie bar burrs, gate burrs and interlead flash, but including any mismatch between the top and bottom of the plastic bod y . 3. these dimensions apply to the flat section of the lead between 0.08mm and 0.15mm from the lead tip. this drawing is for general information onl y . refer to jedec drawing t o-236, v ariation ab for additional information. e1 atmel atsha204 [ datasheet ] 60 8740d ? crypto ? 3 /12 11.2 8 -lead tssop package drawing contact: packagedrawings@atmel.com dr a wing n o . re v . title gpc common dimensions (unit of measure = mm) symbo l min nom max note a - - 1.20 a1 0.05 - 0.15 a2 0.80 1.00 1.05 d 2.90 3.00 3.10 2, 5 e 6.40 bsc e1 4.30 4.40 4.50 3, 5 b 0.19 ? 0.30 4 e 0.65 bsc l 0.45 0.60 0.75 l1 1.00 ref c 0.09 - 0.20 side v iew end v iew t op v iew a2 a l l1 d 1 e1 n b pin 1 indicator this corner e e notes: 1. this drawing is for general information onl y . refer to jedec drawing mo-153, v ariation aa, for proper dimensions, tolerances, datums, etc. 2. dimension d does not include mold flash, protrusions or gate burrs. mold flash, protrusions and gate burrs shall not exceed 0.15 mm (0.006 in) per side. 3. dimension e1 does not include inter-lead flash or protrusions. inter-lead flash and protrusions shall not exceed 0.25 mm (0.010 in) per side. 4. dimension b does not include dambar protrusion. allowable dambar protrusion shall be 0.08 mm total in excess of the b dimension at maximum material condition. dambar cannot be located on the lower radius of the foot. minimum space between protrusion and adjacent lead is 0.07 mm. 5. dimension d and e1 to be determined at datum plane h. 8x d 6/22/11 8x, 8-lead 4.4mm bod y , plastic thin shrink small outline package (tssop) tnr c a1 atmel atsha204 [ datasheet ] 61 8740d ? crypto ? 3 /12 11.3 8 -pad udfn atmel atsha204 [ datasheet ] 62 8740d ? crypto ? 3 /12 11.4 8 -lead soic package drawing contact: packagedrawings@atmel.com dra wing no . rev . title gpc common dimensions (unit of measure = mm) symbol min nom max note a1 0.10 ? 0.25 a 1.35 ? 1.75 b 0.31 ? 0.51 c 0.17 ? 0.25 d 4.80 ? 5.05 e1 3.81 ? 3.99 e 5.79 ? 6.20 e 1.27 bsc l 0.40 ? 1.27 0 ? 8 ? e 1 n top view c e1 end view a b l a1 e d side view 8s1 g 6/22/11 notes: this drawing is for general information onl y . refer to jedec drawing ms-012, v ariation aa for proper dimensions, tolerances, datums, etc. 8s1, 8-lead (0.150? wide body), plastic gull wing small outline (jedec soic) swb atmel atsha204 [ datasheet ] 63 8740d ? crypto ? 3 /12 11.5 3 -l ead contact atmel atsha204 [ datasheet ] 64 8740d ? crypto ? 3 /12 12. ordering information atmel ordering code package type interface configuration atsha204 -sh -cz - t 8 - lead soic, tape and reel single - wire atsha204 -sh -da -t 8 - lead soic, tape and reel i 2 c atsha204 -sh -da -b 8 - lead soic, bulk in tubes i 2 c atsha204 -th -cz - t 8 - lead tssop, tape and reel single - wire atsha204 -th -da -t 8 - lead tssop, tape and reel i 2 c a tsha204- tsu -t 3 - lead sot 23 , tape and reel single - wire atsha204 -mah -cz -t 8 - pad udfn, tape and reel single - wire atsha204 -mah -da -t 8 - pad udfn, tape and reel i 2 c atsha204 - rbh-t 3 -l ead contact , tape and reel single - wire the part number (atmel ordering c ode) does not appear on the package. these packages are marked only with a manufacturing lot number which will likely change from shipment to shipment. do not use the package marking for any incoming inspection process. 13. revision history doc. rev. date com ments 8740d 0 3 /2012 added rbh ? 3 - lead contact package. 8740c 07 /2011 table 8 -4 , command opcodes, short descriptions, and execution times . - change update extra command for typ from 4 to 8 and max from 6 to 12 . change mode: 6 to zone:6 . edit/update write command section . update template . 8740b 04/2011 d ocument update . 8740a 03/2011 initial document release . 14. errata the design should ensure that all i / o pin levels are within the datasheet limits of v ss - 0.5v and v cc +0.5v. the same power supply signal net should be used for both the i / o driver, the v cc pin on the sha204 and any pull - up resistor on the sda pin. failure to adhere to these requirements may result in increased susceptibility to latchup. atmel corporation 2325 orchard parkway san jose, ca 95131 usa tel: (+1)(408) 441 - 0311 fax: (+1)(408) 487 - 2600 www.atmel.com atmel asia limited unit 01 - 5 & 16, 19f bea tower, millennium city 5 418 kwu n tong road kwun tong, kowloon hong kong tel: (+852) 2245 - 6100 fax: (+852) 2722 - 1369 atmel munich gmbh business campus parkring 4 d - 85748 garching b. munich germany tel: (+49) 89 - 31970 - 0 fax: (+49) 89 - 3194621 atmel japan g.k. 16f shin - osaki kangyo bldg. 1 - 6 - 4 osaki , shinagawa - ku tokyo 141 - 0032 japan tel: (+81)(3) 6417 - 0300 fax: (+81)(3) 6417 - 03 70 ? 201 2 atmel corporation. all rights reserved. / rev.: 8740d ? crypto ? 3/12 atmel ? , atmel logo and combinations there of, cryptoauthentication? , enabling unlimited possibilities ? , and others are registered trademarks or trademarks of atmel corporation or its subsidiaries. other terms and product names may be trademarks of others . disclaimer: the information in this document is provided in connection with atmel products. no license, express or implied, by estoppel or otherwise, to any intellectual property right is granted by this document or in connection with the sale of atmel products. except as set forth in the atmel terms and conditions of sales located on the atmel website, atmel assumes no liability whatsoever and disclaims any express, implied or statutory warranty relating to its products including, but not limited to, the implied warranty of merchantability, fitness f or a particular purpose , or non - infringement. in no event shall atmel be liable for any direct, indirect, consequential, punitive, special or incidental damages (including, without limitation, damages for loss and profits, business interruption, or loss of information) arising out of the use or inability to use this document, even if atmel has been advised of the possibility of s uch damages. atmel makes no representations or warranties with respect to the accuracy or completeness of the contents of this doc ument and reserves the right to make changes to specifications and products descriptions at any time without notice. atmel does not make any commitment to update the information contained herein. unless specifically provided o therwise, atmel products are n ot suitable for, and shall not be used in, automotive applications. atmel products are not intended, authorized, or warranted for use as components in applications inte nded to support or sustain life. |
Price & Availability of ATSHA204-SH-DA-T
 |
|
|
|
|
All Rights Reserved © IC-ON-LINE 2003 - 2022 |
| [Add Bookmark] [Contact Us] [Link exchange] [Privacy policy] |
|
Mirror Sites : [www.datasheet.hk]
[www.maxim4u.com] [www.ic-on-line.cn]
[www.ic-on-line.com] [www.ic-on-line.net]
[www.alldatasheet.com.cn]
[www.gdcy.com]
[www.gdcy.net] |